On Wed, 13 Feb 2013, Andrew Deason wrote:
On Wed, 13 Feb 2013 00:32:54 -0500 (EST)
Benjamin Kaduk <[email protected]> wrote:
Anyway, my concern/confusion with this is that the per-server keys
are associated with a server UUID, which I believe is purely a
notion of the
Again, only if the RegisterAddrsAndKey method is used. But we want to
support it, so we must have a way to cope regardless.
I don't think so; if you only use RegisterAddrs but use the per-server
key thing, it's still tied to the UUID. You need to specify the UUID to
AFSCombineTokens in order to get tokens for that server.
You're right, sorry for being snippy.
As you mention later, a BOZO_GetUUID may not be a good idea. I think it
doesn't make a lot of sense to expose the fileserver UUID through that.
While it's conceivable to generate some new bozo-specific UUID to
identify the server, I don't think that's worthwhile.
Yup, that doesn't seem like a useful path to follow.
I assume above you are talking about the case where bosserver remote
access stops working because someone changed the hostname. While I do
think that's annoying, it doesn't need to be as potentially disastrous
as I originally mentioned. It's possible to have the implementation
somewhat check for that at startup, making the error obvious early on.
Using a separate bos identity for each server seems fine.
I was also thinking about having the implementation check at startup. I
don't think it would be a perfect check, but it would probably be enough.
And as has been mentioned, this stuff doesn't need to go in this
document, since it's not for contacting RXAFS, VL, et al. But I could
see a small note about how other AFS services are not specified here,
but they could just use bare gssnegotiate credentials, using their own
per-server identity or the cell-wide key.
That seems reasonable to me.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
