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

[Benjamin Kaduk]

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