Testers wanted: replace utmp with logind
Hi, if you don't know what the problems with utmp in the current form are, here again my blog with background informations: https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/ To make this clear again: this is about _utmp_ only, not wtmp or lastlog and related tools. We don't need systemd for wtmp or lastlog, we have already solutions in Factory for this. systemd v254 will contain all required APIs and currently I'm working with several upstream projects on the necessary changes. Some other Linux distributions are meanwhile helping with this. For the big main tools, PRs are either in discussion or already accepted, but at minimum I have working patches. Now I need some people who are willing to test this on openSUSE Tumbleweed or MicroOS! I'm running meanwhile several machines with this, but I strongly advise against using this on production machines. I have a repository with, where I modified the applications to query logind instead reading /run/utmp: - systemd (utmp disabled, backports from git added) - coreutils - util-linux - procps - pam - openssh - monitoring-plugins - net-snmp How to install them: zypper ar -f https://download.opensuse.org/repositories/home:/kukuk:/no-utmp/openSUSE_Tum... no-utmp zypper dup -r no-utmp --allow-vendor-change reboot Afterwards, there should be no /run/utmp anymore. If an application still creates this file and writes into it, it does not use the glibc API and we have to fix that. I'm especially interested in your experience with who, w, uptime and from people, who use check_users from monitoring-plugins or read the number of users with net-snmp. And I'm also interested which or your favorite tools don't support this yet and I have to look at next. I know there is still a longer list of tools reading /run/utmp, but many of them only count the number of logged in users, so they should be easy to adjust. But we need to find them. And I know there is a huge list of packages trying to write utmp entries, but if they use the glibc API it's no problem, glibc blocks this if there is no utmp file. If you wonder if the number of users shown does not match the output of the old utmp file: we really only show users who did login, no longer all the additional users using xterm instead of e.g. gnome-terminal. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Friday 2023-06-16 14:04, Thorsten Kukuk wrote:
I have a repository with, where I modified the applications to query logind instead reading /run/utmp: - systemd (utmp disabled, backports from git added) - coreutils - util-linux - procps - pam - openssh - monitoring-plugins - net-snmp
Afterwards, there should be no /run/utmp anymore. If an application still creates this file and writes into it, it does not use the glibc API and we have to fix that.
What do you think about making a FUSE-based "utmpfs" that provides just one file (a utmp representation of logind state), bind-mounted to /run/utmp.
I'm especially interested in your experience with who, w, uptime and from people, who use check_users from monitoring-plugins or read the number of users with net-snmp.
screen/xterm/tmux
On Sun, Jun 18, Jan Engelhardt wrote:
On Friday 2023-06-16 14:04, Thorsten Kukuk wrote:
I have a repository with, where I modified the applications to query logind instead reading /run/utmp: - systemd (utmp disabled, backports from git added) - coreutils - util-linux - procps - pam - openssh - monitoring-plugins - net-snmp
Afterwards, there should be no /run/utmp anymore. If an application still creates this file and writes into it, it does not use the glibc API and we have to fix that.
What do you think about making a FUSE-based "utmpfs" that provides just one file (a utmp representation of logind state), bind-mounted to /run/utmp.
??? The utmp format and the API is not Y2038 safe and has many design and security issues. I don't see how your solution solves a single problem of the many problems.
I'm especially interested in your experience with who, w, uptime and from people, who use check_users from monitoring-plugins or read the number of users with net-snmp.
screen/xterm/tmux
??? screen and xterm write useless utmp entries as this are no login sessions, our tmux does not write utmp entires (or did not when I analysed this), gnome-terminal does not write, ksonsole does write, ... So a big chaos, which makes /run/utmp unreliable for everything. Another problem we want to solve with this. And why several upstream projects like the idea. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Monday 2023-06-19 08:27, Thorsten Kukuk wrote:
I'm especially interested in your experience with who, w, uptime and from people, who use check_users from monitoring-plugins or read the number of users with net-snmp.
screen/xterm/tmux
???
screen and xterm write useless utmp entries as this are no login sessions
Well, there is (was?) a use to those entries. In the old days(TM), having one utmp entry per tty (pseudo or not) would help determining a "suitable" tty (most recently active, or one with no program running) that you would pass to the talk/ytalk(1) program when contacting another user. I would make the claim that utmp entries correspond to sessions in the setsid(2) sense, rather than Xorg sessions or postmodern logind sessions. In that sense, tmux not creating utmp entries would be considered a bug, as each tmux window is a process session of its own.
participants (2)
-
Jan Engelhardt
-
Thorsten Kukuk