On Fri, Jun 18, 2010 at 2:56 PM, Chas Williams (CONTRACTOR) <[email protected]> wrote: > In message <[email protected]>,Andrew Deason > writes: >>It's pretty easy to make a supergroup if it's turned on; you may not >>realize it's a specific feature to turn on. Once you have done so, your >>ptdb is now incompatible with ptservers without supergroups enabled. > > this might happen if you ran mis-matched servers. but best practices > would tell you this is a bad idea. >
I think it's considerably worse than that: let's suppose, hypothetically, that it turns out there's a serious bug in the supergroups code, and the easiest solution is to downgrade to a non-supergroups enabled build. Well, unless you know how to hex edit your prdb to remove the group-in-group membership pointers, you're effectively out of luck... Speaking of which, can I propose that over the next few years we move to a model where including code in the build does not implicitly enable it? Active Directory is a common example of this model: they typically decouple code upgrades from schema-changing feature enablements--it is up to the administrator to decide when to "throw the switch" to enable backwards-incompatible features, despite the fact that the code may have supported it for some time. If/when we modify the on-disk format, we're going to run into the same issues, and I'd love to have a plan in place ahead of time to deal with this... -Tom _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
