Dear Developers,
A bit from a Debian user. Please note that I am not come to here to
blame/complain
against the Upstream/Maintainer of the pam package and the Maintainer of
the shadow
package, or come to here to request something. I just come to here to
present
some of my hope.
I often use the w(1)/last(1) command, and sometimes use the lastb(1)
command.
Several days ago, I noticed that records logged in from
console(tty{1..6}) are missing
from the output of last(1) while records from ssh/tmux/lightdm are still
there,
and I started to guess maybe some of my recent changes to the system
caused this.
Today I try to find out what happened, and after several hours of
fruitless effort
(try different options of agetty/login, use strace/gdb on agetty/login
and read
the source of the shadow package), I noticed that a word "pam_lastlog"
in the
source code. Finally I find out the problem is caused by that login(1) use
pam_lastlog.so to write /var/log/wtmp, but pam_lastlog.so was not longer
included
in the libpam-modules package. (It was somehow related to #1068229, but
I missed
it.)
From my understanding, why we need to deal with the Y2038 issue is that
the issue
may cause problems, some of which will be big problems, after year 2038.
But so,
let's now rush some changes, to confuse users or break something? (Just
joke and,
again I am not to blame anyone.) Are there issues using
utmp/wtmp/lastlog and
w(1)/last(1)/lastlog(1), *currently*? Are there security issues, big
defects or
are they hard to maintain?
If not, I prefer a bit more slow pace, compatible and less disturbed
process.
More specifically, regarding to some changes proposed in the wiki [1],
1) I hope there will still be the original
w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1)
tools which can still read *old* format utmp/wtmp/lastlog in Debian at
least for
a while after switch to Y2038-safe replacements. Those tools can read
old format
files without convert/import to new format. I am keeping old wtmp files for
several years. Starting from 2016 my system with a proprietary nvidia
driver failed to
resume from suspend2ram and playing a video using hardware accelerator would
cause the system unstable. Five years later, still having the problem,
with some
help of reading kernel version from `last -f /var/log/wtmp.*', I finally
found
out that there is a commit change in the kernel caused the problem. This
shows
that having those tools installed may provide a few help. Another point
may be
that package from 3rd parties may still write old-format
utmp/wtmp/lastlog, it
will be good still having those tools installed at least for a while.
Those tools
may be modified that when invoked, print messages to inform users
time/date maybe
incorrect after the year 2038, and suggest/recommend/urge users only use
those
tools to read old files and switch to use new replacements. Anyway it seems
keeping those tools have little harm. And I have a look into wtmpdb,
from salsa[2].
From manpage and --help, it seems to me the current version 0.11.0 of
wtmpdb does
not support read/import/migrate from /var/log/wtmp, the suggest of
/usr/bin/wtmpdb
take over last(1) in the wiki is not feasible as some user may still
expect using
`last -f /var/log/wtmp.*' to read old files. Even if new version of
wtmpdb can
read from /var/log/wtmp without import it into
/var/lib/wtmpdb/wtmpdb.db, it is
still good to have a choose to use the original last(1) to read from
/var/log/wtmp.
(Also see below.) It is similar to lastlog2. I see lastlog2 can already
import
from /var/log/lastlog, but from usage() [3], it will always import to a
lastlog2
database.
2) I hope I can choose keeping or deleting the old utmp/wtmp/lastlog
files when
switch to Y2038-safe replacements. By default, those old files may be
automatically
deleted, but before extracting new package/running maint scripts, there
may be a prompt
telling users that those files will be deleted and asking users chose
whether continue
or not; if not, dpkg should exit without deleted those files. Or those
will not be
automatically deleted, instead a Debian.NEWS may be displayed or maint
script can
print a message telling those files can be safely deleted after
converted. I think
the current dpkg already have functions to implement aforementioned
actions as I
have seen something alike many times. I known normally purge a package
will deleted
its log(and configuration), but wtmp/btmp/lastlog/faillog do not belong
to any
package and many program can read from/write to them. Also it seems to
me that
deleting logs during upgrade is not so good, and maybe leave it to users
to decide.
You may ask why I want to keep those old format files instead of
converting them
and use new tools to read? I can not exactly tell why, but I maybe
afraid the
converting may not perfect and I want to compare both output before
deleting the
old ones. For example, the old format files may have 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
