--On Friday, June 18, 2010 04:17:19 PM -0400 Tom Keiser
<tkei...@sinenomine.net> wrote:
On Fri, Jun 18, 2010 at 2:56 PM, Chas Williams (CONTRACTOR)
<c...@cmf.nrl.navy.mil> wrote:
In message <20100618093541.46bc13bc.adea...@sinenomine.net>,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...
No; it's much worse than that. Suppose you upgrade to a new version of
OpenAFS and find there's a serious bug in the fileserver, or ubik, or rx.
Or you missed some "crucial" process step and so it "wasn't OK" to upgrade.
Or someone decides that your upgrade was the cause of their hard disk
failing. So now you want/have to upgrade.
Except the new version of AFS in question had supergroups enabled by
default, and you didn't notice, and some user went and created a
supergroup. So now you can't back out, because your database is no longer
compatible with what you were running before. Perhaps you don't notice
until you actually tried to run the old code, and it just didn't work. You
don't know why it's not working; you may not even notice right away that
you don't have a ptserver -- maybe you only notice the next day when
someone can't access any of their protected files.
OK, perhaps that's a bit extreme. But maybe not. It's not clear to me
that we ever need to reach a point where existing cells upgrading to new
code should automagically get supergroups support. Sure, it should
eventually be turned on by default in a newly-created prdb, but let's not
unnecessarily break things for people who just want to keep their
filesystem working, and especially for people who just want to not be
forced by management to abandon AFS in favor of everyone just giving all of
their files to Google.
-- Jeff
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
