sorted /etc/passwd ?
Rob McMahon
cudcv at wkdaisy.UUCP
Mon Feb 4 05:16:45 AEST 1985
> Message-ID: <330 at lsuc.UUCP>
> I have just added over 1000 accounts for our students, and we
> now have 1526 entries in our /etc/passwd, on a Perkin-Elmer 3220
> running v7. Should I consider sorting them and using a binary
> search? Does anyone have versions of getpw{nam,ent,uid} and anything
> else which would need changing, to implement a binary search?
> (We have a source license.)
At Warwick we have an indexed password file. The password file itself has
fixed length records, and there are two other files which act as indexes into
this by uid and by name.
This means that the only programs which *have* to be recompiled with the
new library routines are those which modify the password file, or that use
the shell field, since this is now terminated by a colon instead of a newline.
The fixed length records means that programs which modify the passwd file can
simply rewrite the record they are interested in instead of copying the whole
file somewhere safe, making changes on the way, and then copying or moving it
back over the original (the time taken to do this when you have over 2000
entries is no joke).
The getpwuid routine now just indexes into the uid index, gets the password
file address from there, and then seeks into the password file.
The getpwnam routine does a binary search on the name index to get the
password file address.
Each of these routines checks to see the indexes are up to date before
using them, in case the password file has been modified. passwd, chfn, and
chsh (and one of our own called pwent which changes any field
interactively) just touch the indexes when they are done since they can modify
the password file line in situ.
makeuser inserts the new entry at the appropriate point in the indexes.
deluser just overwrites the password file entry with a 'free' record which is
spotted by the next makeuser, and adjusts the indexes appropriately.
The routines would need slight changes to run on your system, since we have
added some fields to the password file for expiry date, per-process cpu limit
login quota and disk allowance (which is obsolete now we use the 4.2 quotas).
makeuser would probably need major changes, since we have our own standards
for usercodes, login directories etc. There are also programs to convert from
variable-length- to fixed-length-records, and for recreating the indexes
should they get out of date.
Programs such as ps and ls that create their own in-core password file whilst
reading through for the entry they want, need this code written around to gain
full speed. Most programs benefit just from recompiling. The difference
in speed is impessive. Try an 'ls -l' or 'ps u' or 'f' or even just logging
in without indexes, and with 2000 entries in the passwd file !
Watch out for those programs (like lastcomm) that assume you won't have
uid's greater than 2000 or so and core dump when you do, as well.
If this sounds interesting, mail me, and I'll mail you some source, diffs and
so on. I think there's too much to go on the net.
Rob McMahon
... mcvax!ukc!ubu!daisy!cudcv
More information about the Comp.unix
mailing list