Jacob Volstrup <[EMAIL PROTECTED]> writes:
> 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?
Your problem, specifically, is:
> # /etc/pam.d/common-session
> session optional pam_krb5.so
> session optional pam_openafs_session.so
> session required pam_unix.so
pam_openafs_session will blow away tokens acquired by cron jobs when the
PAM session for the cron job closes.
You have a few options. One is that you could use k5start inside your
cron job, since it creates a new PAG and then runs the command with
tickets and tokens inside that PAG. See:
<http://www.eyrie.org/~eagle/software/kstart/>
Another option is to run your script inside pagsh, which will create a new
PAG and then exec /bin/sh (so you can use it on the #! line of a script,
but not a Perl script of course).
A third option is to use the AFS Perl module and call its setpag function
in your script to put your script in a new PAG. We do this a lot.
A fourth option would be to replace pam_openafs_session with
pam-afs-session from:
<http://www.eyrie.org/~eagle/software/pam-afs-session/>
It doesn't have this problem. It only destroys tokens if it created
tokens.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info