On Monday 03 of February 2014 22:59:39 David C. Rankin wrote: > On 02/03/2014 03:28 PM, David C. Rankin wrote: > > 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. > > Per the suggestion on the freedesktop page, perhaps adding something like > the following around line 1320 of client.c would make explicit the needed > environment: > > if ((pretc = pam_misc_setenv( pamh, XDG_SESSION_CLASS, "greeter", 0 )) != > PAM_SUCCESS) { > ReInitErrorLog(); > LogError( "pam_misc_setenv() for %s failed: %s\n", > curuser, pam_strerror( pamh, pretc ) ); > return 0; > } > if ((pretc = pam_misc_setenv( pamh, XDG_SEAT, "seat0", 0 )) != > PAM_SUCCESS) { ReInitErrorLog(); > LogError( "pam_misc_setenv() for %s failed: %s\n", > curuser, pam_strerror( pamh, pretc ) ); > return 0; > } > if ((pretc = pam_misc_setenv( pamh, XDG_VTNR, "7", 0 )) != PAM_SUCCESS) { > ReInitErrorLog(); > LogError( "pam_misc_setenv() for %s failed: %s\n", > curuser, pam_strerror( pamh, pretc ) ); > return 0; > } > > ** check syntax, this is my guess at it or we could use something like: > > pam_putenv(pamh, "XDG_SESSION_CLASS=greeter"); > > instead of pam_misc_setenv. Other than that, the other area where I don't > fully understand what is needed is in #3 - "Make sure to register your > logged in session via the PAM session stack as well, also including > pam_systemd in it." That may already be done, but I would like to > understand a bit better how/where logged in user registration takes place > and what it means to include pam_systemd in it? Now I read it again and if I understand it correctly, is that about correct setting PAM => no need to change the source code of TDM? Slavek --