[AFS3-std] Re: rxgk-afs tokens for ptservers, etc.

[Jeffrey Hutzelman]

On Tue, 2013-02-12 at 23:25 -0500, Benjamin Kaduk wrote:

> We bundle fileserver/volserver (using tokens from AFSCombineTokens), and 
> ptserver/vlserver are "clearly" expected to use tokens from GSSNegotiate 
> (i.e., with the cell-wide key).


> The kaserver needs to die and has no reason to use rxgk.

The kaserver doesn't even use rxkad, except for KAM (the admin service).
Even that has no need for rxgk, since it's fairly well tied to what the
kaserver does.  I think it can safely be ignored.


> What, then, of the updateserver and the backup suite?  I must confess to 
> have never deployed an upserver and an only passing acquaintance with the 
> architecture of the backup suite, so take the following with a grain of 
> salt.

> It looks like there is a single central update server, which every server 
> machine in the cell contacts (acting as clients) to poll for updates. 
> That would imply that the update server should have the cell-wide key and 
> be able to accept tokens from GSSNegotiate.

Possibly.  On the other hand, the upserver might just as usefully use a
host-based service.  It is a management tool that is not particularly
tied to the AFS service other than by being shipped in the same source
tree.  I sort of wonder how many people are even still using it.


> The backup situation looks more complicated, but I guess the buservers are 
> database servers and act thusly with regard to accepting tokens.  I 
> suppose we should support departmental admins running a butc on their own 
> fileserver to backup the volumes hosted there.  That would seem to imply 
> that butc should accept per-server tokens; I guess implementors will need 
> ensure that bos and volser will accept printed (?) tokens using the 
> per-server key so that such a local butc would work.

No, butc is not a component that runs on fileservers.  It's the tape
controller, and runs in places that have tape drives, or whatever passes
for them.  Volume dumps are obtained from fileservers via the volume
dump mechanism.  To my recollection, butc is also actually not really a
server.  It gets run by an admin, with admin credentials.

In any case, I'm not convinced that either the upserver or the backup
suite are actually part of the protocol suite we're standardizing,
rather than simply implementation-specific tools which ship with
OpenAFS.



> If the local bosserver/volserver/butc will need access to the per-server 
> key, that means the per-server key will probably end up on disk somewhere. 
> Which doesn't really seem like a problem, just something to note.

It needs to be on disk anyway, because it needs to survive a fileserver
restart.  Otherwise, restarting a server would invalidate all of the
tokens issued for it.  Not to mention a variety of other problems.
Also, in a world where fileservers don't know the cell key, the
fileserver's secret key is what it uses to authenticate to the vlserver
for registration purposes.


-- Jeff