Plasma5 user sessions

Thu Feb 1 20:10:08 UTC 2018

Hi,
i used to work with max, and i wanted to comment for a bit. please bear
with me for a minute.

Am 29.01.2018 um 23:11 schrieb Roman Gilg:
> I'm no expert on the init sequence and also not on SysOps, but from a
> developer perspective diverging from upstream by patching a major
> software piece like plasma-workspace in order to solve a particular
> setup problem should always only be considered at the very end.

Believe me, the developers at limux really would prefer not to change
sourcecode. And if it is only because they have to maintain the patchset
themselves and ALWAYS have to look at the larger codebase if something
else breaks their functionality.

> Especially in your case you want to use some undocumented and
> obviously not very abstract routine (startkde) to hook into. Does the
> documentation imply anywhere that you have the right to expect that
> the startkde script is not exited early and you can wrap it? I think
> it does not and even if it does, there is the question if this is
> really the most canonical approach. I would say the more canonical
> approach would be to use the $HOME/.config/plasma-workspace/env
> directory or systemd user services.

The problem ist and always was that there is not in any Desktop
Environment a possibility to set up/tear down user and application
configuration before and after the DE-Environment login and logout
procedure. Administrators *NEED* that.

in all fairness, me and my colleagues always argued how much interaction
with that system was needed, but the current possibilities for
non-developers who administer large amounts of desktop lack that
functionality severely.

We tried to communicate that issue in the past, but when we talked about
user and application configuration KDE always assumed we talk about
KDE-applications though we talked about generic applications which have
to be preconfigured or post-cleanup-action-ed. That was a problem on our
side as well.

> Regarding the scripts in the env directory being under user control:
> Is this really an issue? How many users will delete these files? Can
> you not restore them in this case with a small setup script not in
> user control? And I don't know if it's bad practice, but the first
> thing I thought of was to own the env directory by a higher privileged
> user and make the directory non-writeable to your users, so they just
> can't delete these files.

You do not want to build a system for creating user configuration and
application configuration with scripts with root privileges. BECAUSE the
people who write this configuration scripts almost always lack the
competence (think about service desk or firstlevel people) to write
stable and secure scripts.
otherwise you might end up having scripts configuring user space which
screw up and suddenly the user is able to elevate herself to root with
the login- or logout scripts provided by first- or secondlevel personal
which has administrative privileges.

Therefore with limux we always went with scripts which have only user
privileges (and a few sudo calls within, which we always could inspect
thoroughly).

> Regarding the systemd user services: Is it really necessary that your
> startup scripts run in sequence before the workspace loads? If you

Yes. Believe people who ran a Desktop Linux for 10 years on more than
10k computers for normal office staff and semi- and highly skilled
adminstrators, with direct feedback from users, administrators and
project managers. that might sound condescending, but we experienced
real problems with the infrastructure which we always worked around. and
a few years ago we had not the man power (and the understanding) what
and how communicate that to the community.

sorry.

> think so, maybe it would be better to patch your startup scripts so
> they can run in parallel. I can't directly think of a reason why this
> should not work for tasks like setting up network shares and so on.

That should be an option, not always be the case, because some
applications depend on each other and the created configuration (think
of a application which depends on java and the application has a plugin,
and all three components have to be configured separately. Yes, user
applications can be a nightmare.)

> Anyways good luck and I hope the solution you decide upon in the end
> works fine for your setup.

I would REALLY hope, the KDE community think about the problem
thoroughly. Per-user generic application configuration setup and
teardown is in my opinion the linux-desktop lacks.

IMHO Max should held a talk about that at fosdem, but it is too late for
that.

> Cheers
> Roman

Cheers to you, too.

Dennis

> On Thu, Jan 18, 2018 at 10:06 AM, Max Harmathy <max.harmathy at web.de> wrote:
>> Am 15.01.2018 um 14:32 schrieb Max Harmathy:
>>> Greetings from Munich's LiMux developers team.
>>>
>>> short story:
>>>
>>> * during user session initialisation notifications get displayed as windows
>>> * if one user requests a shutdown (reboot, poweroff) all sessions get killed
>>>
>>> long story:
>>>
>>> We are currently in development of our next (final?) release. Our
>>> current release is based on Ubuntu 14.04 trust, whereas our next release
>>> will be based on Ubuntu 18.04 bionic.
>>>
>>> Thus we switch from
>>> * upstart to systemd
>>> * ConsoleKit to logind
>>> * KDM to SDDM
>>> * Plasma 4.x to Plasma 5.x
>>>
>>> We have to execute some tasks for every user who logs into a computer.
>>> This includes configuring start menu applications, configuring printers,
>>> mounting network shares and synchronise the users home directory with a
>>> filer (downsync). We also provide slots where administrators can run
>>> scripts in the user context.
>>>
>>> Up until now we hooked into the user session by putting some files into
>>> /etc/X11/Xsession.d which is as far as we understand executed by the
>>> display-manager when a x11 user session gets initialised.
>>>
>>> During these configuration steps there are some notifications we want to
>>> be displayed after the desktop is ready. Therefore we collect such
>>> messages. The a script in /etc/xdg/autostart displays them after the
>>> plasma session started as normal desktop notifications. Therefore the
>>> script sends them through the DBus session bus via
>>> org.freedesktop.Notifications. However on our development release those
>>> messages get displayed as windows instead of the usual bubbles. It seems
>>> that the notification handling is not ready when the autostarts are running.
>>>
>>> When the user ends the session we also run code to synchronise the home
>>> directory (upsync), umnount network shares etc. This works as expected
>>> if the user does a simple logout. However if the user requests a
>>> shutdown (reboot, poweroff) then the session and other user sessions are
>>> killed and the computer shuts down. The KSMServer
>>> (plasma-workspace/ksmserver/server.cpp, void KSMServer::cleanUp()) uses
>>> a KDisplayManager (plasma-workspace/libkworkspace/kdisplaymanager.cpp)
>>> which sends a "Reboot" or "PowerOff" through the system bus to logind.
>>> This results in an immediate shutdown and neither our code nor parts of
>>> the startkde script is executed.
>>>
>>> Comments in kdisplaymanager.cpp state that there should be a policykit
>>> dialog preventing a shutdown if other sessions are running, which is not
>>> displayed in our case. But also without other sessions running, the
>>> logout should finish in a clean way(wait for startkde to terminate).
>>>
>>> We found out, that running a process with a systemd inhibitor as root e.g
>>>> # systemd-inhibit --what=shutdown --mode=block sleep 365d
>>> prevents the system from killing the session and a clean logout is
>>> conducted. However in this case also the shutdown request is silently
>>> ignored.
>>>
>>> There are some questions we where not able to find answers by ourselves:
>>>
>>> Is there a definition when xdg-autostart applications are started?
>>>
>>> Is there a way to make sure that the session is ready to display
>>> notifications?
>>>
>>> It seems that sending dbus messages to logind in kdisplaymanager.cpp is
>>> too early. Could this be a general issue? Should this not be the last
>>> part of startkde?
>>>
>>> Could this be a misconfiguration of policykit?
>>>
>>> Could it be that the behaviour of logind changed recently?
>>>
>>> It looks like there are currently some weak spots with plasma5 sessions.
>>> We hope that we can work together to make the users session handling
>>> more robust.
>>>
>>
>> I familiarised myself with session handling with logind [1]. I also
>> looked at what GNOME is doing [2].
>>
>> I have come to the conclusion, that we will most likely patch
>> plasma-workspace not to send DBus requests to logind. Instead we will
>> record the request of the user (with a flag file) and handle it during
>> logout after startkde terminated and our configuration tasks have finished.
>>
>> Nevertheless I think that the session handling in the KDisaplayManager
>> code has a severe issue in conjunction with logind. Therefore I opened a
>> ticket on Bugzilla[3].
>>
>> Max
>>
>> [1] https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/
>> [2] https://git.gnome.org/browse/gnome-session/
>> [3] https://bugs.kde.org/show_bug.cgi?id=389144
> 