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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
