[OpenAFS-devel] Re: [OpenAFS] Re: 1.6 and post-1.6 OpenAFS branch management and schedule

[Jeffrey Hutzelman]

--On Friday, June 18, 2010 04:17:19 PM -0400 Tom Keiser=20
<tkeiser@sinenomine.net> wrote:

> On Fri, Jun 18, 2010 at 2:56 PM, Chas Williams (CONTRACTOR)
> <chas@cmf.nrl.navy.mil> wrote:
>> In message <20100618093541.46bc13bc.adeason@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. =C2=A0but 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=20
OpenAFS and find there's a serious bug in the fileserver, or ubik, or rx.=20
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=20
failing.  So now you want/have to upgrade.

Except the new version of AFS in question had supergroups enabled by=20
default, and you didn't notice, and some user went and created a=20
supergroup.  So now you can't back out, because your database is no longer=20
compatible with what you were running before.  Perhaps you don't notice=20
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=20
you don't have a ptserver -- maybe you only notice the next day when=20
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=20
that we ever need to reach a point where existing cells upgrading to new=20
code should automagically get supergroups support.  Sure, it should=20
eventually be turned on by default in a newly-created prdb, but let's not=20
unnecessarily break things for people who just want to keep their=20
filesystem working, and especially for people who just want to not be=20
forced by management to abandon AFS in favor of everyone just giving all of =

their files to Google.

-- Jeff