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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
