[OpenAFS] Cron, script and keytab on Ubuntu x86
Douglas E. Engert
Thu, 15 Feb 2007 14:52:44 -0600
OK, so it looks like a no problem with the pam_openafs_session.so
deleting the token.
What is really needed is a pam_* that just gets a PAG. and maybe
a pam_krb5 that sets the KRB5CCNAME even without getting a ticket.
But in the mean time, you could change try changing your crontab entry
to have: /usr/bin/pagsh -c consctipt-initialize.pl
i.e. run /usr/bin/pagsh that gets a PAG and then execs /bin/sh.
/bin/sh then runs your original the script is perl.
So this could be a one line change in crontab.
Jacob Volstrup wrote:
> tor, 15 02 2007 kl. 09:34 -0600, skrev Douglas E. Engert:
>>> * The short version *
>>> I have a keytab which is used from my cronscript. The script is executed
>>> every 5 minutes and has a local non-AFS lockfile to prevent multiple
>>> scripts working on data at the same time.
>>> For convenience we call the running script R and the starting/checking
>>> script S. The S script exits if the lockfile exists, if not it
>>> initializes the AFS credentials with kinit and the keytab file and
>>> becomes R. When S exits R will loose its AFS credentials, which is the
>>> part I just do not understand as I would expect that the different
>>> executions of the cronjob have their own running environment.
>> Ubuntu has a /etc/pam.d/cron file. It calls common-account and
>> common-session. Do you have any pam routines that could be deleting
>> the token? It sounds like your job is not run in its own PAG
>> so it using a shared PAG for the user the job is running under.
>> Some debug options on the pam routines might show something.
>> Add some klist and tokens commands to you script might also help.
> With klist I got the information needed to find out that a new cronjob
> is running within the same environment as the previous cronjob (as my
> suspicion was telling me). This kind of explains why the token does not
> remain for the first occurrence of the cronjob.
> Now I just have to find out how to let each cronjob run in their very
> own environment. I have been looking at my pam configuration but cannot
> seem to find any errors or solutions. Maybe I need another option in my
> pam configuration?
> # /etc/pam.d/cron
> @include common-auth
> auth required pam_env.so
> @include common-account
> @include common-session
> # Sets up user limits, please define limits for cron tasks
> # through /etc/security/limits.conf
> session required pam_limits.so
> # /etc/pam.d/common-auth
> auth sufficient pam_krb5.so
> auth required pam_unix.so nullok_secure use_first_pass
> # /etc/pam.d/common-account
> account sufficient pam_krb5.so
> account required pam_unix.so
> # /etc/pam.d/common-session
> session optional pam_krb5.so
> session optional pam_openafs_session.so
> session required pam_unix.so
> Sincerely, Jacob Volstrup
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439