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: #%PAM-1.0 #auth required pam_securetty.so auth requisite pam_nologin.so 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 #%PAM-1.0 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 session: cat ../pam.d/system-login #%PAM-1.0 auth required pam_tally.so onerr=succeed file=/var/log/faillog auth required pam_shells.so auth requisite pam_nologin.so auth include system-auth account required pam_access.so account required pam_nologin.so account include system-auth password include system-auth session optional pam_loginuid.so session include system-auth session optional pam_motd.so motd=/etc/motd session optional pam_mail.so dir=/var/spool/mail standard quiet -session optional pam_systemd.so session required pam_env.so 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.