[OpenAFS-devel] making supergroups the default and removing the option?

[Marcus Watts]

Derrick J Brashear <shadow@dementia.org> writes:

> (Message inbox:32910)
> 
> Date:    Fri, 17 Aug 2007 23:09:50 EDT
> To:      openafs-devel@openafs.org
> From:    Derrick J Brashear <shadow@dementia.org>
> Subject: Re: [OpenAFS-devel] making supergroups the default and removing the op
>      ***tion?
> 
> On Fri, 17 Aug 2007, Jason Edgecombe wrote:
> 
> > Hi everyone,
> >
> > While on IRC, Chris Clausen suggested making the SUPERGROUPS option the 
> > default and removing the option to disable it. I know that this changes the 
> > ptserver behaves.
> 
> Enabling it in the pts (client) always is harmless regardless. Enabling it 
> in the server isn't really an issue either to the extent that we do it 
> only in 1.5 and not change the behavior for a minor release (1.4.5)
> 
> I believe (and hopefully Marcus will correct me if I'm wrong) it would be 
> trivial to make supergroups enabled in binaries without changing any 
> behavior, by simply changing the default of depthsg in ptutils.c to 0 from 
> 5.

[I'm going to try to answer what a few other people asked as well.]

supergroups client support just adds more rpc's -- this is
indeed harmless even for cells without supergroup support.

supergroups server support adds extra code to implement
the server side support for supergroups, including new rpcs.
depthsg doesn't make that extra code appear, it merely limits
how much it will do.  I believe the limit is merely upon reads,
so depthsg = 0 won't stop you from creating supergroups, it
just guarantees they won't be honored.

Running mixed supergroup & non-supergroup db servers probably won't
destroy your cell, but it will cause weird schizoid behavior.  If your
sync site happens to support supergroups, you can make supergroups and
they'll be correctly propagated to the slave sites.  If your sync site
doesn't happen to do this, you won't be able to change anything about
supergroups.  Slave sites that don't understand supergroups won't break,
but will return different read results when asked about something affected
by supergroups.  If your sync site flip-flops about understanding
supergroups, the non-supergroup aware db server can break groups
that contain supergroups.  Don't do this.

Backing out supergroups; assuming you avoid schzoid behavior, backing
this out is easy: remove all {group is a member of a group} memberships,
then swap binaries out.  Additionally: you should already be backing
up your db files regularly, & you should certainly have made a
snapshot of them when you upgraded binaries.  If you have to go back
to the last "non-supergroups" db backup, you should be in acceptable
state.

You should probably have a copy of db_verify & pt_util when you make this
change.  pt_util is probably built and installed by default.  You may have
to build db_verify specially.  If you have a copy of "db_verify" - you can
check your database file to be sure it's consistent.  A non-supergroups
version of db_verify will complain quite a lot about any supergroups it
finds.  You can use pt_util to convert your binary db files into text,
at which point you can use diff to see what's different, and this is
also yet another way to find supergroups if you want them to go away.
With these two tools, you can repair any damage you might create with
supergroups (unlikely), reproduce changes made with supergroups
after going back to a non-supergroups db, or make supergroups go away
for sure & good from a db, if you really need to.

This may all seem like supergroups are complicated & hard to deploy.
This is not at all true.  It does require doing something that I think
people in OpenAFS have grown used to not doing: upgrading all your
db servers at once for a server.  Everything else I described, using
db_verify etc, are all worst-case disaster scenarios, also, they're the
same tools you would have been using all along to repair any damage
to your pt database.  In transarc days, having to upgrade db servers
synchronously was a common feature with upgrades.  People managed to cope
just fine.  While supergroups may be the first reason openafs folks have
to deal with incompatible db versions, it's hardly the last: there are
future changes coming down the pike that will also need incompatible
db changes, including: K5 names in pt, and an expanded VL format.  Or,
here's a less obvious incomaptible db change: when do you want ubik to
not use rxkad/des between servers?

				-Marcus Watts