Results 1 to 1 of 1
I've worked with *nix since 4.1BSD on VAXs and lastlog (formerly utmp) has always just been a file indexed by uid. Recently I've been converting linux systems to use Active ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 10-12-2008 #1
- Join Date
- Oct 2008
lastlog should be a db
I've worked with *nix since 4.1BSD on VAXs and lastlog (formerly utmp) has always just been a file indexed by uid. Recently I've been converting linux systems to use Active Directory LDAP for authentication and authorization and I ran into a problem. To avoid having the uids from AD conflict with uids in /etc/passwd, the AD folks started numbering their uids at 10,000,000. The result is a 30GB lastlog file. Of course, it's a sparse file, so it really only takes 70KB, but it's a problem just waiting to happen. Accidently copy it, tar it, rsync it without using the "sparse" option and it becomes 30GB, possibly filling /var/log. Of course an obvious solution is to ask the AD folks to start numbering at some lower value (say, 100,000), but thinking about this, it occurs to me a better solution might be to replace lastlog with lastlog.db and just use uid as the hash key. Bring lastlog into the 21th century. Question is, who really maintains the source for things like lastlog, finger, who, /bin/login, etc?
By the way, some linux (notably 64bit) have a 1.2TB lastlog because the nsfnobody account in /etc/passwd has uid -1 (2^32*sizeof(struct utmp)). Definitely need to be careful to use the "sparse" options when manipulating that puppy.