Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:

> As others have stated, utmpx is just utmp with bigger field lengths.
> This is the Wrong Answer.

It's not necessarily the Right Answer, but I wouldn't call it the
Wrong Answer either.

> Something closer to the right answer involves defining a new API for
> reading utmp/wtmp, and revving the existing utmp-updating API
> (-lutil's login/logout/logwtmp) to keep the old files up to date so we
> don't really need a "/dev/utmp" to hallucinate the old file.  
> 
> There's existing prior art for this (there's the getut*/putut* calls
> in solaris), but unfortunately they just use the existing "struct utmp"
> with its fixed-length fields.

Yes, this is what applications that grovel around in utmp expect. I'm
surprised that those functions doesn't exist already. Having yet
another different implementation of utmp* is not going to help the
world.

>  - for network logins, both the hostname and the sockaddr should be
> logged, since the address<->host binding varies over time, and logging
> the client port number and, for V6, the interface index is also
> interesting.

Sure.

>  - I'd use db for the utmp and lastlog replacement (utmp keyed by
> "line", while lastlog keyed by either uid or login name), 

Why use a database for this? The task is so simple that you don't
really need it, and (as others have pointed out) DB has it's
drawbacks.

> and a plain text file for the wtmp replacement.

Isn't it a good idea to keep utmp and wtmp in the same format? If you
just want a text file, what's wrong with syslog?

/Johan