Dear Maintainers of util-linux and sysvinit source packages,

Since util-linux 2.40.2-12 dropped utmpdump, there are no tools in the archive
capable of interrogating log files in the utmp(5) format.

I appreciate that the utmp-capable tooling has been removed from default
installations to avoid users being misled that they are appropriate for
administering current systems since the move to wtmpdb. However, I don't think
that is a reason why they should not be available in the archive at all.

I suspect there will be significant unsatisfied demand for tools in the next
stable release that are capable of reading log files previously populated with
information in utmp format.

Both the util-linux and sysvinit source packages are capable of supplying the
last, lastb and utmpdump tools. Could I suggest that between the two groups of
maintainers it be arranged that a new optional binary package be added that
supplies these tools, suitably caveated in the package description?

They could be named something like:

 - util-linux-utmp
 - sysvinit-utmp-utils

As the util-linux version of the tools has been road-tested in Debian for a long
time, this might be a sounder choice for users but if sysvinit is chosen, I
have prepared a PoC of the proposed new package:

https://salsa.debian.org/debian/sysvinit/-/merge_requests/14

Thanks,

Andrew

I think this is misguided. trixie will be the release that underwent
a very painful t64 transition so all software in it is supposed to
continue working past year 2038. For the utmp format, this is AFAIK
not the case.

freeradius also needs to find a solution to write into a file format
that works longer. I imagine if freeradius could use pam, it could
just reuse the wtmpdb stuff.
Isn't there an sql backend available anyway?

Chris

I am aware of the transition; this suggestion is about tools to
interrogate extant files. I expect there will be some demand for them.

I noticed that wtmpdb upstream used the existence of utmpdump in Debian
as a reason why importing those files wasn't urgent, but that premise is
no longer true and yet there is no importer. I think users will be
avoidably disappointed.

Hi Chris,

Firstly, thanks for supporting my contributions to making sure wtmpdb
works well for users!

To expand on my earlier reply:

As a new contributor to Debian I missed helping with the transition -
sorry about that. utmp would work past 2038 except on i386 - and for
32-bit architectures that is thanks to the hard work you all did, thank
you! The big issue with utmp is the certainty of corruption when
accessed by both t64-capable and non t64-capable software.

But this is beside the point because I am not arguing for continued use
of utmp but for the ability to read files already stored in utmp format.
There will be no way for users to do this without fishing around for old
binaries. I don't think we will be thanked for dropping them when we
could so easily have made them available.

I was motivated to raise this suggestion because I know the window is
closing on getting a new binary package into the release. If no one
thinks this is important then I hope I am wrong about how this will land
with upgrading users! I have proposed two ways this could happen - I'll
leave it with you all now.

An import command for wtmpdb would help (although I still think we
should ship the old tools for those who really want them since we have
them). I have been tempted to contribute one myself but like the
upstream author, I also have other priorities!

I think the freeradius people have got their own plan which they are
happy with, so I don't think we need to dwell on it here.  As radius is
about authentication on behalf of other services my guess is this is
about a logging module not the authentication backend and that the host
system's pam and login reporting infrastructure is therefore irrelevant.

This is just using a private facility and so no one else is writing to
the file - it will be y2038-safe if the host is, they are just using the
system tool as a reader for that file because it is generally assumed to
be present. In fact their risk is upon upgrading the OS from
armhf/armel/hppa/m68k/powerpc/sh4 when this file _will_get_corrupted_ -
therefore the most important thing for freeradius is I think that they
forcible rotate that file on upgrade, regardless of what is done or
not done to access or replace it going forwards.

No doubt there is - does it help them read old logs?

Thanks,

Andrew

I think a one time import may be useful on upgrades, yes.

TTBOMK the utmp format did not change on any architecture, so it is
has the year 2038 limitation.

I think reading old files can be done very well using a bookworm
chroot (or whatever container people want to use).

Generally I just don't see reading *old* utmp-format files is an
important usecase. The info in these files is quickly aging; from my
PoV looking at utmp data from more than 6 months ago is a
nonexistent thing to do.

On systems where the act of logging in is relevant, I expect admins
to have set up centralised logging of a login occuring. Very likely
without the involvement of any utmp-format file.

With my non-Debian hat on I can say this is the case for a large
fleet of systems, and using utmp files would not have sprung to our
minds at all.

How so?

Chris

Hi Chris,

Thanks for your reply about the merits of including support for reading
utmp-formatted files. An important technical correction follows below
for any observer reading this thread (mea culpa):
[..]

Sorry, I was simply wrong here, so let me correct the record from my
technical error: when I went in to look at the header (potentially with
a view to contributing an importer) I realised I had not actually
checked it and was relying on false memory of what I had inferred it to
be from skimming discussions about why it _couldn't_ be changed,
thinking it had indeed been changed (or rather, how it might have
already changed by virtue of relying on time_t). The limitation does
apply, as you say.

(This was of course a side issue anyway as I was not disputing the merit
of changing from utmp, just access to tooling.)

As discussed above, this is indeed incorrect.