> > Now that we are increasing the number of hosts that are in our Kerberos
> > realm, one thought comes to mind: the current method for managing
> > srvtabs really bites.
> >
> > Specifically, the thought of doing "ark host/foo", "xst foo host", etc
> > etc, a billion times is giving me screaming nightmares.
> >
> > I am wondering what larger sites do w.r.t. srvtab management. Are there
> > any custom scripts that people use? Do people actually change the keys
> > in the srvtabs, or do they leave them at the initial value?
>
> A co-worker of mine wrote a utility called shkbob, which works with the ADM
> administration server in use here. The way it works (correct me if I goof,
> Rob?) is each principal for which instances can be created has a set of
> ACLs controlling things like who can create and delete instances. You can
> log into a random machine as a user with said privilege, run shkbob, and it
> uses rxkad crypt to secure a connection the ADM server, which creates a key
> and passes it back to you. Ideally, you log into said machine on console.
We have a pair of programs, kreghost and ksrvhost, which are used for this
process. kreghost allows admins to generate and register random keys for
workstations, which are then displayed as a 16-digit hex number. So that
everyone who builds machines doesn't have to be a kerberos admin, we have
a mechanism that lets certain users log in to the kerberos server as a
special user (authenticated, of course), and then create rcmd keys for any
machine.
Once you have the 16-digit key for a machine, ksrvhost will actually
create a srvtab file; it's intended to be run on the machine that's being
keyed. So, the distribution problem is solved by moving 16-digit numbers
around on paper, and destroying them afterward. Our standard machine
install process consists of doing the OS vendor's install followed by
running our local install script, which among other things runs ksrvhost.
So, all you have to do when building a new machine is create a key, and
then type it in when requested.
> > : And as a site note, how many people _really_ use a floppy/tape
> drive/whatever
> > : to send the srvtab to various machines, and how many people just ftp
> > it : over in the clear? I know that the stuff in the srvtabs should
> > never go : in the clear, but since you only do it once ...
> >
> > Then of course the one part people often forget is that when the go and
> > remotely backup / on their systems it goes across in the clear again,
> > and again, and again.... (This should be documented!)
>
> Any workstations which we back up use Amanda for backups, and we have it
> configured to encrypt dumps of / as they go over the network, at least.
In the few cases where a machine is to be keyed for which ksrvhost is not
available, yes, we really use a floppy (or, in rare cases, tape) to move
the srvtab file around. Once is all it takes...
Due to the number of machines and amount of disk space we have to back up,
efficiency is a major concern. We can't afford the processing time it
would take to encrypt backups. However, we do use a custom version of
dump that, among other things, can be told not to dump certain files
(/etc/srvtab, all of /usr/vice/cache, and so on...)
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Systems Programmer, CMU SCS Research Facility
Please send requests and problem reports to [EMAIL PROTECTED]
