cron on AFS files]

[Marcus Watts]

Peter Scott <Peter.J.Scott@jpl.nasa.gov> writes:
> 
> Assuming the solution you're talking about is gettoken (which came from 
> UMich, though, not CERN), the only scalability issue I'm aware of with it 
> is that it can only contact a single authentication server.  I have been 
> wanting for some time to convert it to use redundant servers a la klog, but 
> I don't know how.

The umich version of gettoken uses (and so far as I know has alway used)
the K4 routine send_to_kdc to contact the "authentication servers".
send_to_kdc has logic in it to step through a list of servers
in /etc/krb.conf, one at a time.  It *will* be slower if the 1st one
is down.

The advantage of gettoken is that it uses a srvtab and not a user
password.  The srvtab still needs to be stored somewhere on the local
machine, and is a security issue, but it's not quite as bad as
storing a naked plaintext password.

I doubt this is the same thing that Martin Gasthurber is talking
about.  Assuming his description is accurate, whatever he's using
stores an AFS ticket along with the job, and uses that ticket - if the
job is scheduled to run after the ticket expires, too bad.  Presumably
that's at least a part of the scalability problems and operational
difficulties Martin mentions.  The fact it's just an AFS token probably
further limits its usefulness.  I think K5 has support in it for
post-dated tickets and control over which IP addresses that ticket
can be used, which might make it a better, but still not ideal solution.

				-Marcus Watts
				UM ITCS Umich Systems Group