Re: Y2038-safe replacements for utmp/wtmp and lastlog

2024-05-30 Thread Jun MO

On Thu, 30 May 2024 13:18:17 +0200, Vincent Lefevre wrote:
> I agree, this may be useful. Unfortunately, the current status is
> that one cannot have both: installing wtmpdb forces the upgrade of
> util-linux to 2.40.1-3 (at least), where "last" is no longer installed.

Thanks for the change about version 2.40.1-3 of the util-linux package.
This is indeed mentioned in the NEWS.Debian from the 2.40.1-3 util-linux
package, and the NEWS.Debian also suggests installing wtmpdb. But
the last(1) from wtmpdb can not read /var/log/wtmp:

$ last -f /var/log/wtmp
wtmpdb_read_all: SQL error: file is not a database

And if I understood correctly, wtmpdb require program use PAM to update
wtmpdb, thus program not use PAM will still write /var/log/wtmp. For
example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux
depends on pam. But now one can not read /var/log/wtmp neither from
util-linux or wtmpdb. Fortunately, last(1) only links to linux-vdso.so.1,
libc.so.6 and ld-linux-x86-64.so.2. One can extract the /usr/bin/last
binary from old util-linux .deb which can be downloaded from
snapshot.debian.org.

> However, I think that it is better to archive human-readable text files
> (generated by "last" in the past) rather than the wtmp files.
>
> I've used the attached script to get both the IP addresses and the
> host names with "last" (I don't know whether there's a better way to
> get full information).

I agree that human-readable text files are better than the wtmp binary
format files, if the text files provide all information or at least
information one wanted to keep. I find that last(1) may not print all
information, and you need some option to let it print something fully;
so I personally still prefer to keep those wtmp files. For example,
I have noted that the IPv6 address in the output of `last' is truncated
long time ago, and find just a couple of months ago that the -a option
will put the full address in the last column(I see you use that option
in your script). And the output from rotated files(e.g wtmp.1) may have
something like "gone - no logout". Provided the wtmp files are just
many "records" of raw data of C struct of "utmp"(defined in utmp.h, or
see `man 5 utmp'), one record for login, one record for logout,
one record for boot, etc, one can do something like:

$ cat /var/log/wtmp.1 /var/log/wtmp >> wtmp-combined
$ last -f wtmp-combined

The output will show when a user logout for those previously
"gone - no logout" lines. I just realize this about a month ago.

I know there is a utmpdump(1) in the util-linux package, that is still
available in 2.40.1-3 version. The command will dump more information
than last(1); but it is for every single records, one may need to
manually match login with logout, boot with shutdown, etc. Still it
seems to me some information, e.g. exit_status, are still missing.
For archive season, one may write a program that read the wtmp files
and dump all variables of the struct utmp.

And something "off topic". I find there is a char __glibc_reserved[20]
variable in the struct utmp, which is commented as "Reserved for
future use". Just a brainstorm, if this variable is not currently used,
maybe it can be used to solve the Y2038 problem for wtmp?

Regards,
Jun MO



Re: Y2038-safe replacements for utmp/wtmp and lastlog

2024-05-08 Thread Jun MO

On Wed, 8 May 2024 at 09:21:35 +1000, Craig Small  wrote:

> I can only speak for w.  It currently prefers what it gets from 
systemd or

> elogind, effectively
> iterating over the sessions coming from sd_get_sessions() if sd_booted()
> returns true.
>
> If sd_booted() returns false, then it uses the old utmp/utmpx files for
> now. Besides the Y2038
> issue, the utmp "API" is pretty awful with things like errors pretty much
> undetectable. There is also
> the problem about who (e.g. which process) should be writing to those 
files

> as you have pointed out
> in your email.
>
> For now w/uptime will use utmp as a fallback, but I'll be happy if this
> gets updated to something better; it's a low-priority
> for me because systemd/elogind do what I need most of the time.

Thanks for explaining.

For last(1) my concern is that it will be helped to keep the original
last(1) for back-compatibility to read old wtmp files. For w(1), utmp
is only about current sessions, so there is no need to keep years-old
utmp files. Unlike last(1), there is no something like `w -f /run/utmp'.
Actually, one can run `last -f /run/utmp', and it provides output
similar to w(1)'s except missing something like process and CPU times
for each user. And as pointed out by you, w(1) currently already prefer
using infos from systemd/elogind instead of reading from utmp.

So I now think w(1) may be little need to keep the ability to read from
utmp and am also happy to it can change to use something better.

Regards,
Jun MO



Re: Y2038-safe replacements for utmp/wtmp and lastlog

2024-05-07 Thread Jun MO
 corrupted, and the 
converting
silently skip what it can not parse. Or for no reason, I just want keep 
those

file in a original intact form.

So for summary, I hope original last(1)/lastlog(1) etc. can still in 
Debian after adopted
Y2038-safe replacements and I could chose whether to delete 
utmp/wtmp/lastlog files
or not before upgrade a package. Or more generally, I hope changes can 
be performed
in a compatible and less disturbed process, or if it can not be avoided, 
at least
I could be informed and choose what to do before it happened. It will be 
very
appreciate if these can be take into consideration before decides being 
made.


Another note, in my system, I found some packages do not use PAM to 
write utmp/wtmp.
screen/tmux/xfce4-terminal depend on libutempter0 which provide a 
library and
a setgid helper to write utmp/wtmp. The runit package provides 
utmpset(8) which
can wirte a logout record to utmp/wtmp. Once in Debian but removed a 
while ago,

the sac package has writetmp(1)/rawtmp(1) which can also write to wtmp.
These package, maybe among others, may be needed to modify to write to
Y2038-safe replacements.

Last, thanks for your works and your reading.

Regards,
Jun MO

[1] https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb
[2] https://salsa.debian.org/debian/wtmpdb
[3] 
https://github.com/util-linux/util-linux/blob/926b6077333554924756ba648c9df38c803c48bc/misc-utils/lastlog2.c#L103