0

I see the following syslog entries about once or twice a day on one of my servers. This server backs up files to AFS space using a Kerberos service principal:

Dec  6 04:01:06 myserver kernel: [3681180.757245] afs: Tokens for user of AFS id -1 for cell realm.example.com have expired (server 192.168.22.24)

The server is running Debian wheezy 64-bit. What can I do to track down what might be causing this message?

user35042
  • 2,601
  • 10
  • 32
  • 57
  • The -1 id bit is really odd. All I can think is somehow an unsigned int is being put in a signed int format. But even that doesn't really address the problem. – Fred the Magic Wonder Dog Dec 09 '13 at 15:41
  • Is is possible that the kerberos service principal does not have a pts entry? `pts ex kerberos_service_principal`. The -1 could also be that some routine is returning an error code that is not being properly checked. – Fred the Magic Wonder Dog Dec 09 '13 at 19:16

1 Answers1

1

A likely reason for the -1 id is just that the tokens were destroyed at around the same time that message appeared. Either someone 'unlog'd the tokens, or (more likely) the periodic house-cleaning processes in the kernel module noticed that the tokens were expired and invalidated them. An id of -1 is one way that tokens are flagged as invalid (this is the ViceId in the 'unixuser' struct in the openafs kernel module). If you always see an id -1 in that message, it's not really possible to really know what is specifically triggering those messages, unless there are only a few things running at that time that are authenticated to AFS.

If you are not already using it, you should be using k5start or krenew (both in package 'kstart' in Debian) with the -t option to ensure that your process for backing up files has nonexpired tokens for accessing AFS.

If you are using k5start, though, it is still possible to have access fail with expired tokens due to some edge cases in how the -K option works: http://permalink.gmane.org/gmane.comp.encryption.kerberos.general/18343 . Since k5start with -K only guarantees that its krb5 tickets are valid for 2 minutes in the future, it's possible to obtain AFS tokens that are valid for around 2 minutes or less in the future. If those 2-minute-valid tokens are used to contact the AFS fileserver, and the communication takes longer than 2 minutes, access can fail with "tokens expired". Or if the maximum ticket lifetime for the AFS service principal is less than the maximum ticket lifetime for the TGT, the AFS tokens may expire before your tickets do, and so k5start would let them expire.

You can ensure that does not happen by increasing the guaranteed ticket lifetime by using the -H option together with the -K option. Just set -H to something higher than the 2 minute default; maybe 30 minutes or an hour. Or you can use the -a option to always renew tickets every time k5start/krenew wakes up (this is what I would recommend). However, everything in the paragraph is impossible with the latest released version of k5start, so in order to do this you need to wait for a new release of k5start, or build it from git.

Another way to solve this is to not use k5start, and have your own scripting run something like kinit -kt /path/to/keytab && aklog every hour, in the same PAG as the process backing up files into AFS.

adeason
  • 106
  • 2