[OpenAFS] upgrade caused script to stop working correctly

[John Koyle]

Jared Smith wrote:
> I am upgrading each of my developers testing environment and have
> upgraded from Kubuntu Edgy to Kubuntu Hardy.  In doing so the afs
> client is behaving differently.  On Edgy I ran a customized init
> script (afstokengrabber.sh) during boot that called another script
> (reauth.pl) that obtained a kerberos ticket and afs tokens for my
> apache/tomcat user (wwwrun) and renewed them about every 4 hours.  I
> do this because the web application is stored in their home dir which
> is on AFS.  This all worked fine.  Afstokengrabber.sh runs as root and
> has this line that calls reauth.pl
>
> start-stop-daemon --start -c wwwrun --exec /var/lib/wwwrun/reauth.pl
>
> reauth.pl has these two main lines in it
>
> kinit -k -t /var/lib/wwwrun/devuser.keytab devuser
> aklog
>
> this worked great in Edgy, wwwrun would get it's tickets and tokens,
> tomcat could access the webapp stored in afs everyone was happy.  Now
> that I upgraded to Hardy and set things up the same the behavior
> changes.  Now wwwrun user gets kerberos tickets but root user gets the
> tokens.  I can't for the life of me get wwwrun user to get tokens.  I
> tried using k5start as well but got the same results, root got tokens
> while wwwrun got tickets.  I am not an afs guru but I think it has
> something to do with the PAG.  I tried using pagsh in the scripts to
> somehow get it to work but no results.  Wondering if anyone has
> suggestions of how to get around my obstacle.
> In a nutshell I need the apache/tomcat user to constantly have a
> ticket and token so it can access the webapp stored on afs.  I need
> the token to work across different console sessions so they don't have
> to worry about keeping a certain one up and running.  It works
> perfectly now.  I am assuming that some improvements to the afs client
> has change how things run now all I need to do is adjust my scripts
> but I have run out of ideas.  Hope someone out there understands my
> gibberish and has an idea for me.  I know the answer is probably
> staring me in the face I just can't see it.

I had a similar issue recently.  We solved it by switching to Russ
Albery's (thanks Russ!) pam_krb5 and pam-afs-session modules from here:
http://www.eyrie.org/~eagle/software/

and then setting up the common-session pam stack as follows so that
PAG's are not created for sessions on that host.

session optional        pam_afs_session.so nopag retain_after_close

HTH,
John