On Thu, 14 Feb 2013 15:28:52 -0500 (EST) Benjamin Kaduk <[email protected]> wrote:
> Now we get into what is probably just implementation questions. Yes, I think everything in here is up to the implementor, but this warrants some recommendations. It could also be possible to mention all of the different schemes that have been brought up here, and briefly mention the pros/cons. I don't think you need to decide yet what OpenAFS does for this. > On the other hand, if a fileserver is to be upgraded from rxkad to > rxgk, there needs to be some way to indicate in the configuration that > it is ready to do so, otherwise all rxkad fileservers are subject to > hijacking by a rogue RegisterAddrsAndKey call. I think the distinction here is between cell-wide-key fileservers and per-server-key fileservers; rxkad or not doesn't really matter. A fileserver with the rxgk cell-wide key should be able to upgrade itself without intervention. And if you convert a fileserver from cell-wide-key to per-server-key, you need to have an administrator flag the UUID somehow, or else the fileserver could hijack any rxkad or cell-wide-key rxgk fileserver vldb entry. I'm thinking of this as just a general administrator command to change the UUID<->GSS mappings. You'd need the same thing if you change the e.g. kerberos principal used by a fileserver (say, if it's hostname changed, and you want the principal name to accurately reflect the hostname). -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
