On Sun, Feb 09, 2025 at 08:46:39AM +0000, Andrew Bower wrote: > To expand on my earlier reply: > > On Sun, Feb 09, 2025 at 01:01:08AM +0100, Chris Hofstaedtler wrote: > > On Sat, Feb 08, 2025 at 12:47:05PM +0000, Andrew Bower wrote: > > > 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. > > > > 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.
> 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. I think a one time import may be useful on upgrades, yes. > 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. TTBOMK the utmp format did not change on any architecture, so it is has the year 2038 limitation. > 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! That's somehow the thing: priorities and importance. 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. > 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_ - How so? Chris
