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

[Benjamin Kaduk]

On Tue, 12 Feb 2013, Jeffrey Hutzelman wrote:

> On Tue, 2013-02-12 at 20:55 +0000, Chaskiel Grundman wrote:
>>>  [Last paragraph of section 3]
>>>  Tokens returned from the GSSNegotiate call MUST only be used with
>>>   database servers.  Tokens for fileservers MUST be obtained by calling
>>>   AFSCombineTokens before each server is contacted.
>>>
>>> Without context, that doesn't seem clear to me whether it means the
>> database server processes and the fileserver process, or if it means the >
>> actual machines.
>>
>> Interpreting this as actual machines makes the most sense here.
>
> Operationally, maybe, but in terms of code structure and the way server
> implementations work, I think not.

I agree.

[trim details of the motivation for why]
>
>
> Finally, I think the rule as it applies to fileservers also needs to
> apply to volservers.  Among other things...
>
>>  One of the
>> purposes for all this complexity is so that fileserver machines (running
>> bosserver, fileserver and volserver processes) can have unique keys not
>> shared with all the other server hosts in the cell. This is somewhat simpler
>> administratively, but also enables a cell to have servers administered by
>> multiple groups that don't trust each other (everyone must trust the
>> database server maintainers, but that's it)
>
>
> And if that's the case, then you need a server-specific token to talk to
> a volserver.

Yup, it really seems like the volserver and fileserver are pretty tied 
together.  (Along with the salvager, though I don't recall that we ever 
talk directly to the salvager.)

> I'm not sure what to do about the bosserver.  It's really more of a
> management tool than part of the main protocol suite.  It seems like, at
> a minimum, it ought to be possible to obtain a token for a given
> bosserver by negotiating directly with that server, the same as for any
> other rxgk service.  Arguably the same should be possible for volservers
> and maybe even fileservers, though in practice that doesn't seem as
> useful.

I'll put more thoughts on the bosserver in a separate mail.

For now, I want to double-check if there is anything that is missing from 
this list of server processes that may need to be contacted over an 
rxgk-secured connection:
fileserver
(cache manager callback "server", already has its own thread)
ptserver
vlserver
kaserver
volserver
bosserver (deferred)
updateserver
buserver
butc

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.

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.
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.

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.
Unless we want each of them to register in the vldb as their own uuid in 
some sort of dummy setup, but that smells like a hack...

Does that feel like a reasonable partition for the various services?

-Ben