Dear folks, since we have to test elogind now with various setups, KatolaZ asked me to write a short guide what needs to be tested. So here we go:
Lets start with a short overview about what logind is: It is about session, user and seat management. Its main use is to track who is logged in by which method into a system and which processes belong to such a session. A session can then be assigned to a seat. Seat can be a remote access, x11 display... That information is then used by other software packages to determine e.g. access permissions to hardware. This topic was addressed with another software some time ago, called consolekit. Many desktop environments and tools have been added support for consolekit. e.g. KDE, GNOME, udisks, upower. At some time (e)logind was born in context of systemd. (elogind) implements the same functionality like consolekit and more. Today more and more applications are migrated to (e)logind. Therefor this package is needed in Devuan to support modern Desktop Environments. For now, lots of packages in devuan assci still rely or can use consolekit but this might change in future. This includes udisks (consolekit only), KDE (maybe both). Some packages require (e)logind, e.g. GNOME, for installing the package but at runtime they seem also be able to still use consolekit. In principle consolekit and (e)logind can be used at the same time because the use different D-Bus APIs and consolekit is merely a database. But applications must implement this. Main testing point is to figure out if elogind breaks anything which is formerly working properly. In the currently prepared packages, elogind is although being installed and started, not fully enabled because my internal tests showed that this breaks user mounting, shutdown and reboot via consolekit. This probably requires changes to other packages. We still need to know if anything else breaks by installing the elogind package, or if things become functional after installing it. We need information about as many combinations of display managers and desktop environments as possible, because there is interaction between elogind and all of them and things which work with one display manager and one desktop environment might not work with another display manager. I have tested so far: - text login - lightdm/KDE - lightdm/GNOME (only basic tests) So for testing, you might take with the following steps: - just install packages "elogind" and "libpam-elogind" package and check if they install cleanly. I expect problems when original systemd packages are used. Report any problems with it - invoke "pam-auth-update" as root and ensure that elogind is not selected. This will effectively disable eloginds session management (daemon still runs and dbus api/library is available) - after installing, invoke the command "loginctl". It should not list any session because elogind is not (yet) fully enabled. - After installing, check if login/logout works properly. Especially the graphical logins are interesting. Please report tested display manager / desktop environment here. - Now check if you can mount/unmount removeable media like USB, CDs. Report if it worked before installing elogind and if it still works afterwards - Test if reboot/shutdown via desktop environment is functional. Report if it worked before installing elogind and if it still works afterwards - Now, we should test with fully enabled elogind. Todo so invoke "pam-auth-update" again and enable elogind. Afterwards logout and login again. From now on, if any unexpected behavior occurs, things which work before, please report them. - executing "loginctl" should now list the session. - Now check if you can mount/unmount removeable media like USB, CDs. - Test if reboot/shutdown via desktop environment is functional. As said above, elogind is doing more than only recording the sessions. So with fully enabled elogind the following things should be tested: - Test if reboot/shutdown works via "loginctl poweroff" and "loginctl reboot" - When using the "screen" terminal emulator original logind is killing everything, even the multiplexed application when the session closes. Please test if that happens for your system. I think we have to preconfigure it reasonable here. - When terminating a session with a kill command, I have observed on debian, that the user services survive this and continue running. That means, that if the sessions crashes gpg-agent might be still running and if logging in again it might still have opened the key (not asking for passphrase) I think one can kill the session using the kill command and the login as another user and figure out if there are still processes running under the former user to test this. Thanks for your help.
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
