How we propagate password information in our fileserver infrastructure
June 27, 2010
As mentioned earlier, we have a fileserver infrastructure and so we need some way of propagating account and password information around (and letting people actually update their passwords). The old traditional answer is NIS, the new traditional answer is LDAP, and we don't really like either so we wrote our own.
Given the the Unix system UID problem, any such system has three parts: where each machine's account information lives, how global account information propagates around, and how you combine global accounts and system accounts together.
Our answer to the first question is that each machine has a complete
local copy of
(We also feel nervous about adding another point of failure to our fileserver infrastructure in the form of a master account machine that must be up in order for anyone to be able to log in anywhere.)
We've also chosen a simple way to handle propagating the global account
information around; we use our existing fileserver infrastructure. We
have a central administrative filesystem where the global
(The use of an NFS filesystem is really a small implementation detail.
Our Solaris fileservers use the same
system and programs to keep their
The update process is somewhat complicated. First, the global
We propagate updates to global accounts by periodically running
an update script that extracts all of the system accounts from
(This avoids having to change the root password on every single system we have, which would be a great disincentive to changing it at all.)
In the process of handling global accounts, the program allows us to both selectively exclude (or only include) some and to selectively or unselectively mangle accounts in various ways. We can change shells (for example to give accounts a shell that just tells them they can't log in to this machine), remap where home directories are in various useful ways, and so on. Also, if there is a conflict between a system login or group name and a global login or group name, it renames the global login or group by sticking a prefix on it.
(Naturally we put the update script itself in the central administrative filesystem too, because that makes maintaining it simpler. The only thing that lives on the client machines is the crontab entry that invokes the whole system every so often.)
Password changes are handled by a cover script for
(The details of how things work on the password master machine are somewhat complicated, so I'm not going to put them here.)
Written on 27 June 2010.
* * *
Atom feeds are available; see the bottom of most pages.