== How we propagate password information in our fileserver infrastructure

As mentioned [[earlier FileserverInfrastructure]], 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 UnixSystemUIDProblem]], 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 _/etc/passwd_, _/etc/shadow_, and _/etc/group_. This is
the simple approach, because everything is guaranteed to work with local
files since that is how single, isolated machines work.

(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 _passwd_,
_shadow_, and _group_ files live, and every client machine NFS mounts it
under a standard name. The one complication of the NFS mount approach is
that client machines must have root access to the filesystem in order
to read the global _shadow_ file, which means that we have to be very
careful about which machines we allow to have write access to it.

(The use of an NFS filesystem is really a small implementation detail.
Our [[Solaris fileservers ../solaris/ZFSFileserverSetup]] use the same
system and programs to keep their _/etc/passwd_ in sync, but they don't
NFS mount the administrative filesystem because we don't believe in NFS
crossmounts on the fileservers. Instead they copy the files over with
_rsync_.)

The update process is somewhat complicated. First, the global _passwd_
et al is the authoritative source of global accounts, while each
machine's _/etc/passwd_ et al is the authoritative source of its local
system accounts. We tell the two apart based on UID and GID; our global
user logins and groups are always within a specific UID and GID range
(one that is chosen to not clash with local system UIDs and GIDs).

We propagate updates to global accounts by periodically running
an update script that extracts all of the system accounts from
_/etc/passwd_, extracts all of the global accounts from our master
_passwd_, merges the two together, and writes out an updated
_/etc/passwd_ et al if anything changed. Because it's convenient, this
also updates the passwords of any system accounts from the global
_shadow_ file if they're present there.

(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 _passwd_ that
ssh's off to our password master machine and runs the real _passwd_
program there. The global _passwd_ et al are just straight copies of
the password master machine's _/etc/passwd_ et al, although they get
run through a checking program before they get copied from _/etc_ into
the central administrative filesystem. This is an important safeguard
against stupid mistakes when updating the master machine's _/etc/passwd_
et al.

(The details of how things work on the password master machine are
somewhat complicated, so I'm not going to put them here.)