Hi Chris, Firstly, thanks for supporting my contributions to making sure wtmpdb works well for users!
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. 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! > 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. 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. > Isn't there an sql backend available anyway? No doubt there is - does it help them read old logs? Thanks, Andrew
