[GE users] AFS authentication

Reuti reuti at staff.uni-marburg.de
Thu Dec 1 18:54:05 GMT 2005


Hi,

Am 01.12.2005 um 19:39 schrieb Kirk Patton:

> Perhaps my original note was to involved.   :-)
>
> Here is the short version.
>
> Is there any way in SGE to have a job run an external command *before*
> any other job setup is done?  ie.(setting working directory,  
> opening filehandles...)
> I need to run an external command to authenticate a user so they  
> can get access to the
> file system.

this could be done a queue prolog. There you can setup create  
directories, which could be deleted in an epilog - and in between be  
used by the job. But I'm not sure, whether this is what you want. If  
you want to setup some things, which should be inherited to the job  
script, you might use a starter_method (man queue_conf) for this  
queue instead, which will have sone more commands therein:

#!/bin/sh
#
# . ~/.bash_profile # Maybe it's necessary
# Define something here before the exec, e.g. the authentication
exec $*

Cheers - Reuti


> Thanks,
> Kirk
>
> On Wed, Nov 30, 2005 at 12:12:56PM -0800, Kirk Patton wrote:
>> Hello all,
>>
>> I have been working on a workaround to support AFS with SGE, but  
>> it is turning into a bit
>> of a kludge.  I was wondering if there is a better way, or if the  
>> possibility exists to
>> get SGE to better support AFS/kerberos.
>>
>> We are using AFS to keep design data secure.  The problem is that  
>> in order to access this
>> data, a user needs to run the klog command to get their AFS  
>> tokens.  SGE expects to be able
>> to change to the submission directory and open log files there for  
>> stdout.  If the submission
>> directory is in protected AFS space, the job fails unless the user  
>> has already klog'ed.
>>
>> I have been able to work around this to some extent.  I have  
>> automated the granting of
>> tickets by writing my own external program that reads the users  
>> AFS password from an
>> encrypted file.  It then calls the klog program to grant the  
>> tickets on the target SGE
>> host.  I use the queue "starter_method" parameter to invoke my  
>> program before the
>> job is started.  It seems to work o.k. in my initial testing, but  
>> I have to do some
>> juggling with the current working directory so that the job does  
>> not land in AFS
>> space before it is authenticated.
>>
>> I recently ran into another related problem when specifying '-o  
>> out_file'. If the
>> jobs stdout is told to go to the current directory, and that  
>> directory is in AFS
>> space, it appears that an attempt to open the file happens before  
>> my starter_method
>> can get the tokens granted.  So, the job fails.
>>
>> What I think I need for this to work more smoothly would be to  
>> have some way in SGE
>> to specify that an external program needs to run before the job  
>> setup is begun.
>>
>> If it were possible to run my authentication program on the target  
>> host before any
>> other job setup had been attempted, the program could grant the  
>> AFS tokens, and
>> I would not have to mess around with the current working  
>> directory, or tell my
>> user that they cannot specify AFS space for their jobs output files.
>>
>> Does anyone have any comments on how best to support AFS with  
>> SGE?  To further
>> complicate things, one of our AFS cells is not under local  
>> control, so any suggestion
>> that requires messing with the AFS cell would not work in my  
>> situation.
>>
>> Any suggestions are appreciated. :-)
>>
>> Thanks,
>> Kirk
>>
>> -- 
>> Kirk Patton
>> Unix Administrator
>> Transmeta Inc.
>>
>> ----- End forwarded message -----
>>
>> -- 
>> Kirk Patton
>> Unix Administrator
>> Transmeta Inc.
>> Tel. 408 919-3055
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>
>
> -- 
> Kirk Patton
> Unix Administrator
> Transmeta Inc.
> Tel. 408 919-3055
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list