trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2014

Re: [trinity-devel] Bug 1902 - pam.d and preprocessor checks surrounding consolekit may be part of issue

From: "David C. Rankin" <drankinatty@...>
Date: Wed, 26 Feb 2014 23:27:21 -0600
On 02/26/2014 07:55 PM, Slávek Banko wrote:
> Detailed information I mentioned in the bug report 1902. I accepted the part 
> that this is a problem that need to be solved. But I have to say that at the 
> present time it is absolutely useless to distract our attention with patch 
> for full support systemd multi-seats, because it is not related to this 
> problem.

OK,

  If not needed or if it won't help, then we can pursue another avenue, but in
researching the migration requirements:

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!

The multiseat patch does part of #2 and all of #4, so I fail to see how that is
a 'distraction'? What the problem is -- is that the TDE code needs MORE than
just a migration to systemd. There are parts of the code that DO NOT work in a
clean-systemd environment on-and-above the freedesktop migration requirements.
That's fair, but it doesn't make implementing the multiseat patch a distraction,
it just means that implementing multiseat will not solve all the problems :(

Even though the patch multiseat patch did not fix those problem, the upside is
that the port of the patch builds and installs without any adverse impact on TDE
bringing tdm that much closer to being up to date.

Now, do you have anything beyond tdebase-kdesktop-systemd.diff that I can help
test? Let me know. If not, I'll go add more print statements and try to figure
out where you are going with your dbus solution and where Francios was going
with the dumps he made.

One thing I did find out was that kdm (kde4) was still virtually identical to
tdm as far as implementing the multiseat patch, so it may be worth taking a look
at the kde4 kdm files regarding the tdeio issue since it has probably already
been solved in a manner we can port directly to tde rather than reinventing the
wheel.

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