cron on AFS files]

Peter Scott
Fri, 02 Mar 2001 17:40:33 -0800

At 08:23 PM 3/2/01 -0500, Marcus Watts wrote:
>Peter Scott <> 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.

But most of our AFS clients don't have an /etc/krb.conf.  That's why our 
primary authentication server has the alias 'kerberos', because we don't 
have the ability to dictate the contents of /etc/krb.conf or environment 
variables on the users' workstations.  Yet klog manages to exercise 
redundancy in the face of this... how?

>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,

How do you do that?  Sorry, my ignorance is showing.

>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.

Peter Scott