On Wed, 13 Feb 2013, Simon Wilkinson wrote:
On 12 Feb 2013, at 22:06, Jeffrey Hutzelman wrote:
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.
The approach I took with bosservers was to treat them as a completely
different service. It's hard to define what cell a bosserver belongs to,
as well as the need to be able to talk to bos before the vlserver is up.
So, making them separate from the afs3 service seemed to make a lot of
sense.
Just to make sure I'm understanding correctly, "completely different
service" means that you do not attempt to use a cell-wide key to
negotiate a token with the RXGK_GSSNegotiate service offered by a
bosserver?
In this model, all machines running bos have their own
afs3-bos/machine.name@REALM key. There is a gss negotiation service
running on the bosserver port which is used purely for connections to
bos. The downside of this is that we no longer use tokens held in the
kernel for connections to bos. This might result in some user confusion
where their tokens don't match the contents of their Kerberos
credentials cache, but does mean that bos can be used from machines
which aren't running a cache manager.
Hmm, being able to use bos without a cache manager could be nice.
I see the point that the bosservers are a completely different service,
essentially an administrative service tied to a particular machine. After
all, all the bos commands require a server argument (and there's not a
ubik database behind them or anything). However, I do like the ability to
treat dbserver machines as interchangable, or even as identical (in the
sense that they are just different faces of the same distributed
database); this makes me inclined to allow the dbserver machines to use
the cell-wide key (aka the afs-rxgk@_afs.<cellname> GSS identity) for
fielding GSSNegotiate calls on the bosserver port. Do you oppose allowing
this? I guess it would make the code more complicated, with the client
needing to try both the cell-wide identity and a server-specific identity.
I'll think about it more; I could still be convinced that always using an
afs-bos (or afs3-bos? We should be consistent about whether we use a '3')
identity for bosserver tokens is the right thing to to.
I'm having second thoughts about the BOZO_GetUUID proposal I made last
night; it seems to be violating some abstraction barriers.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
