Using and Administering

Handling an AFS Token

You can write a program, run by the scheduler, to refresh an AFS token when a job is started. To invoke the program, use the following keyword in your configuration file:

AFS_GETNEWTOKEN = myprog

where myprog is a filter that receives the AFS authentication information on standard input and writes the new information to standard output. The filter is run when the job is scheduled to run and can be used to refresh a token which expired when the job was queued.

Before running the program, LoadLeveler sets up standard input and standard output as pipes between the program and LoadLeveler. LoadLeveler also sets up the following environment variables:

LOADL_STEP_OWNER

The owner (UNIX user name) of the job

LOADL_STEP_COMMAND

The name of the command the user's job step invokes.

LOADL_STEP_CLASS

The class this job step will run.

LOADL_STEP_ID

The step identifier, generated by LoadLeveler.

LOADL_JOB_CPU_LIMIT

The number of CPU seconds the job is limited to.

LOADL_WALL_LIMIT

The number of wall clock seconds the job is limited to.

LoadLeveler writes the following current AFS credentials, in order, over the standard input pipe:

The ktc_principal structure indicating the service.

The ktc_principal structure indicating the client.

The ktc_token structure containing the credentials.

The ktc_principal structure is defined in the AFS header file afs_rxkad.h. The ktc_token structure is defined in the AFS header file afs_auth.h.

LoadLeveler expects to read these same structures in the same order from the standard output pipe, except these should be refreshed credentials produced by the user exit.

The user exit can modify the passed credentials (to extend their lifetime) and pass them back, or it can obtain new credentials. LoadLeveler takes whatever is returned and uses it to authenticate the user prior to starting the user's job.