[torquedev] Other batch systems and Kerberos (was Fwd: Re:
[Beowulf] network filesystem)
garrick at clusterresources.com
Tue Mar 6 13:39:49 MST 2007
On Tue, Mar 06, 2007 at 09:14:57PM +0100, Sergio Gelato alleged:
> * Bj?rn Torkelsson [2007-03-06 18:42:27 +0100]:
> > On Tue, 2007-03-06 at 10:21 +0100, Sergio Gelato wrote:
> > > The solution to limited Kerberos ticket lifetimes is well-known, and
> > > involves renewable tickets. (Essentially, the ticket lifetime determines
> > > how often one must generate a new session key while the renewable lifetime
> > > determines for how long one can go on doing so. The former should not exceed
> > > a few hours, the latter can be months.) The job server needs either to
> > > periodically renew tickets for jobs in the queue, or to be able to acquire
> > > fresh ones when a job is started.
> > In this case I think the lifetime of the ticket has to be at least as
> > long as the runtime of the job, or every mom have to be able to renew
> > the tickets, which probably complicates things. At least initially.
> I don't think so. It's quite easy for a job to do a
> (while kinit -Rf; do sleep 30000; done) &
> or equivalent (e.g., Russ Allbery's krenew) on each node. Indeed it would
> be nice for pbs_mom to set that up on the user's behalf and to clean up at
> the end of the job. Isn't this what the prologue and epilogue scripts
> are for?
I thought the pro/epilog bits were no longer necessary. When the gssapi
patch was originally submitted, I was the one that rejected the idea of
pro/epilog scripts managing the key renewals.
I had thought the pbs_mom bits required to handle this were already in
checked in to the gssapi branch.
More information about the torquedev