Progress on my OpenAFS server project halted a few weeks ago. To properly use an OpenAFS cell at home one has to run a Kerberos5 password database. Mistakenly, I thought that this conflicted with the Kerberos5 setup I use to allow me to work from home and access the OpenAFS cells at work.

This is because the commonly used Kerberos command line utilities only allow you to operate on a single ticket-granting ticket at a time. If you get a new TGT from another realm, the TGT from the first realm dies. (In theory, the Kerberos5 protocol and libraries don’t actually enforce this, just the commonly used utilities like kinit). Foolishly, I’d assumed I wouldn’t be able to get tokens for my personal OpenAFS cell while simultaneously working out of the OpenAFS cells at work.

There is nothing that prevents this. Nothing.

bwdezend@godzilla:[/afs/gurucollege.homelan/photography] $ tokens

Tokens held by the Cache Manager:

User's (AFS ID 502) tokens for [email protected] [Expires Apr 11 07:38]
User's (AFS ID ID#) tokens for afs@cell1 [Expires Apr 11 18:50]
User's (AFS ID ID#) tokens for afs@cell2 [Expires Apr 11 18:50]
User's (AFS ID ID#) tokens for afs@cell3 [Expires Apr 11 18:50]
   --End of list--
bwdezend@godzilla:[/afs/gurucollege.homelan/photography] $ klist
Credentials cache: API:502:6
        Principal: [email protected]

  Issued           Expires          Principal
Apr 10 21:38:40  Apr 11 07:38:40  krbtgt/[email protected]
Apr 10 21:39:57  Apr 11 07:38:40  afs/[email protected]

Now, the project can proceed.