Long-running jobs with renewal of krb5 tickets and AFS tokens

[Rainer Laatsch]

At our AFS cell rrz.uni-koeln.de, we run Sun's batch system SGE. We expect 
on job submission the user has an AFS token. Just that. This gets 
transferred as a special encrypted comment within the job.

The SGE is AFS aware. On job start and every refresh period (say some 
hours) the job shephard, running in the same PAG as the users job, 
transmits the token to a VlServer (needs the KeyFile) for refresh. Instead 
of the former (obsolete?) arc/arcd we use SSH (with a forced command) as 
the transport medium on a separate SSHD port with special  sshd_config & 
authorized_keys files.

The token may be valid or not and will stay so; just the time validity is 
refreshed. If that was the *only* disturbation the batch will get a good 
token back.

The user job effectively needs an AFS token. The above method is 
straight forward. Fiddling with interim Krb5 tickets is no help. Keytabs
are a bad idea.

Best regards
Rainer

-------------------------------------------------------------------------------
On Mon, 16 Mar 2009, Simon Wilkinson wrote:

>
> On 28 Feb 2009, at 23:04, Thomas Kula wrote:
>
>> On Sat, Feb 28, 2009 at 05:42:58PM -0500, Jason Edgecombe wrote:
>>> We have users who need to run long-running jobs and store their
>>> files in
>>> AFS during the run.
>>>
>>> I've read the k5start and k5renew man pages, but I don't see how I
>>> can
>>> have users type in their password when they start a job and have the
>>> tickets and tokens keep being renewed.
>>>
>>> How can I do this?
>>
>> Give them a keytab, but not one for their normal identity (this
>> breaks things). Create, rather, an instance for them that can
>> be put in a keytab
>
> We (Informatics @ Edinburgh) are developing an identity management
> system which provides a user-friendly interface both to allow a user
> to create a new instance from their primary one, and to allow them to
> assign access control entitlements from their primary instance to the
> one they've just created. I'll be talking about, and demoing it, at
> this years AFS & Kerberos Best Practices Workshop.
>
> Cheers,
>
> Simon.
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>