Hi Russ, since "fixing" the vservers by exposing the hosts's /proc/fs/openafs/afs_ioctl, our services that rely on k5start to get and maintain their tokens are losing their afs tokens.
It seems somewhat random so far - the ColdFusion process in one vserver lost its token after running for several days and even restarting the vserver didn't get a usable token back (even though a "tokens" command in the startup script did show that tokens had been granted, ColdFusion didn't get access to afs). The apache process in one vserver seems to lose tokens within a couple of days (it's happened about three or four times so far). Since we were using a fairly old copy of k5start, I tried re-building k5start from: http://archives.eyrie.org/software/kerberos/kstart-3.13.tar.gz but it didn't seem to fix the problem. Moving a vserver to a host that doesn't expose /proc/fs/openafs/afs_ioctl does seem to fix the problem. Do you know what might be causing the problem? We're using debian-provided kernels from etch (stable): linux-image-2.6.18-6-xen-vserver-686 Here's an example of how we're using k5start with these services: (excerpt from /etc/init.d/apache2 script on a web server that uses afs for the DocumentRoot) K5PRINC="wwwsrvr" K5PIDFILE=/var/run/$NAME-k5.pid K5TKTFILE=/tmp/apache2-$K5PRINC.tkt K5DAEMON=/usr/local/bin/k5start K5OPTS="-k $K5TKTFILE -p $K5PIDFILE -b -K 60 -t -f /etc/$K5PRINC.tab $K5PRINC" SSD=`which start-stop-daemon` and then in the "start" section: $SSD --start --pidfile $K5PIDFILE --exec $K5DAEMON -- $K5OPTS and in the "stop" section: $SSD --stop --pidfile $K5PIDFILE rm -f $K5PIDFILE and in the "restart" section: $SSD --stop --pidfile $K5PIDFILE rm -f $K5PIDFILE sleep 10 $SSD --start --pidfile $K5PIDFILE --exec $K5DAEMON -- $K5OPTS -Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
