Message: previous - next
Month: February 2014

Re: [trinity-devel] TDE running on systemd will require code changes proper session tracking?

From: "David C. Rankin" <drankinatty@...>
Date: Mon, 03 Feb 2014 15:28:36 -0600
On 02/03/2014 02:58 PM, David C. Rankin wrote:
> On 02/03/2014 02:41 PM, Slávek Banko wrote:
>> Outside of that was found in tdebase, XDG_SESSION_COOKIE is used in kpowersave 
>> and tdepowersave (will be fixed after commit patch from bug 1597). This is 
>> good news - on the ConsoleKit no more dependent - only TDM. In other words, 
>> it should be enough to add support for SystemD session into TDM. I will try 
>> to assess how difficult this task is...
>> Slavek
> That is good news! Also, at least for tdebase, the preprocessor checks already
> exclude the console kit code when not defined. Checking the running processes,
> it looks like everything required from Arch is already started and running:
> /sbin/init
> /usr/lib/systemd/systemd-journald
> /usr/lib/systemd/systemd-udevd
> /usr/lib/systemd/systemd-logind
> /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile
> --systemd-activation
> /sbin/agetty --noclear tty1
> /opt/trinity/bin/tdm
>  \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-LI4Qla
>  \_ -:0
>      \_ /bin/sh /opt/trinity/bin/starttde
>          \_ /opt/trinity/bin/tdeinit_phase1
>              \_ kwrapper ksmserver --windowmanager twin
> /usr/bin/gpg-agent --daemon
> /usr/bin/ssh-agent -s
> dcopserver [tdeinit] --nosid --suicide
> kded [tdeinit] --new-startup
> start_tdeinit --new-startup +kcminit_startup
> All we need is to provide is the minimum porting requirements:
> Minimal porting (without multi-seat) requires the following:
> 1. Remove/disable all code responsible for registering your service with ConsoleKit.
> 2. Make sure to register your greeter session via the PAM session stack, and
> make sure the PAM session modules include pam_systemd. Also, make sure to set
> the session class to "greeter." This may be done by setting the environment
> variable XDG_SESSION_CLASS to "greeter" with pam_misc_setenv() or setting the
> "class=greeter" option in the pam_systemd module, in order to allow applications
> to filter out greeter sessions from normal login sessions.
> 3. Make sure to register your logged in session via the PAM session stack as
> well, also including pam_systemd in it.
> 4. Optionally, use pam_misc_setenv() to set the environment variables XDG_SEAT
> and XDG_VTNR. The former should contain "seat0", the latter the VT number your
> session runs on. pam_systemd can determine these values automatically but it's
> nice to pass these variables anyway. In summary: porting a display manager from
> ConsoleKit to systemd primarily means removing code, not necessarily adding any
> new code. Here, a cheers to simplicity!
> It looks like #2 is where the work is. Coding wizard like you - no sweat..

  I don't know if this helps or not, but I noticed that mkpamserv installed as
part of tdebase and used in the tdebase.install script creates a trinity pam
file with:


#auth       required
auth       requisite
auth       include      system-local-login
account    include      system-local-login
session    include      system-local-login

  The inclusion of system-local-login, include the following:

cat ../pam.d/system-local-login

auth      include   system-login
account   include   system-login
password  include   system-login
session   include   system-login

  Which in-turn includes 'system-login' for each auth, account, password and

cat ../pam.d/system-login

auth       required         onerr=succeed file=/var/log/faillog
auth       required
auth       requisite
auth       include    system-auth

account    required
account    required
account    include    system-auth

password   include    system-auth

session    optional
session    include    system-auth
session    optional          motd=/etc/motd
session    optional          dir=/var/spool/mail standard quiet
-session   optional
session    required

  I don't know if this is common, but that shows what pam modules are
available/called on arch to allow logind/dbus/polit to track and manage user
sessions and device access on arch -- if it makes any difference.

David C. Rankin, J.D.,P.E.