cron on AFS files]
Peter Scott
Peter.J.Scott@jpl.nasa.gov
Fri, 02 Mar 2001 17:40:33 -0800
At 08:23 PM 3/2/01 -0500, Marcus Watts wrote:
>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.
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
Peter.J.Scott@jpl.nasa.gov