[torquedev] Other batch systems and Kerberos (was Fwd: Re: [Beowulf] network filesystem)

[Garrick Staples]

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.