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