On 13 Feb 2013, at 17:21, Benjamin Kaduk <[email protected]> wrote:

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

Correct. bos doesn't use the cell wide rxgk key at all.

> 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);

I think this as abstraction violation. Whilst the service presented by ptserver 
or vlserver makes database servers interchangeable, the platforms upon which 
these services are hosted are not necessarily interchangeable. Bos is just 
another example of this.

For example - a user might choose to host a file server on one (but not all) of 
their database server machines. Multiple cells might be hosted on a single 
machine (so which cell-wide key do you accept?) Migrations may be performed 
where the cells hosted by a machine change without restarting bos, and so on. 
Not all of these things are possible in OpenAFS today, but I don't think we 
should design rxgk based on our current limitations.

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

Yes, I think I do - for the reasons I outline above.

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

For services which have an entry in /etc/services, I think we should maintain 
the Kerberos convention of using that service name for our identities.


S.

_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization

Reply via email to