Site Specific ACL Bits/chown: Was: [OpenAFS-devel] posix chown
again
Matt Benjamin
matt@linuxbox.com
Tue, 09 Dec 2008 11:32:24 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Simon,
In general, I am of the belief that prescriptive rules, here
specifically, the proscription sites _should not have_ site local ACL
bits, disregarding precedent (the entire history of AFS), should have to
meet a far higher standard than 4 people on this list oppose (while at
least 3 have publicly supported, and more support is, of course, out
there for this feature than has weighed in.)
Rather obviously, it should take more than a simple majority of folks
not seeing the purpose of some feature, when one of the largest and most
significant OpenAFS deployments historically and today, worldwide, sees
its merit enough to code and maintain it.
To me, the discussion on principle (and the principles of sound
reasoning) are what matters. I think that anyone who read Jeff
Hutzelman's post should have come away with the realization that there
are important matters of principle at issue here.
Here is my summary, amplifying it with some more:
* OpenAFS needs to stay true to its history, as well as move
forward--that means it needs to take account of the needs of sites like
CMU and (redacted, their preference, this is Derrick's convention of
representing it)--to do otherwise is really unwise (I easily could add
more adjectives here)
* The argument for "uniformity" and against site-local flexibility seems
to be a proxy for a much larger argument against diversity in the code
base, against OpenAFS being more things to more people, where no one is
harmed--the shifting of the argument to be against "too many
configuration options" is the evidence for this
Turning to that, the argument against "too many configuration switches"
is rather like the argument that Mozart used "too many notes." Too many
for what?
Clearly, we should keep all the switches activating the features that
the product and its developers need--all the rest are superfluous. Just
as clearly, "too many configuration switches" is a proxy for blanket
attacks on all the features _you_ don't see the need for, but others
(who created them) did.
More importantly, as I amplify further in my inline comments, the
attempt to justify reduction by reference to maintainer testing
obligations is specious, on multiple levels.
OpenAFS gatekeepers don't need to test all the features the product can
theoretically perform, they only need to test the ones that are
_officially supported_. To argue otherwise is, respectfully, some type
of overreaching.
The simple truth is, OpenAFS has a lot of developers working on features
that need to see wider use, need to see the light of day, and need to be
committed to the main line of OpenAFS development. The message we
developers need to hear is that OpenAFS and its community and leadership
are eager to incorporate as many of those features as it possibly can.
We don't need to hear the message that there are too many configuration
options in OpenAFS--by all means, solve our testing problems, solve them
PLEASE. Or appoint some of us to help solve them. But respectfully, we
have, collectively, a right to expect the solutions to be the best
available, to be sensible, flexible, and well reasoned.
I have always assumed the fair bargain for the right to add new concepts
and implementations to the system, was that I not act to _prevent
others_ from adding features for which they see the need and benefit,
but which I, in my ignorance, do not. That is the ecumenical spirit,
or, if you will, the humility, that essential to our future progress as
a community.
Matt
** In line comments follow:
Simon Wilkinson wrote:
>
> On 8 Dec 2008, at 17:46, Jeffrey Hutzelman wrote:
>
>>> and "is the OpenAFS community prepared to revoke the site
>>> local ACL bits so that there are bits available to assign to a standard
>>> function?"
>>
>> No one's suggesting that should happen.
>
> This has been discussed. I don't think anyone believes that it's a
> realistic option at this time, but it's certainly been bandied about.
It should not have been, for reasons adduced here and in our previous mails.
>
>
> Remember, we're not just talking about different sites, but also about
> potentially different semantics amongst servers at the same site. We're
> also talking about a situation where the meaning of a private use value
> can differ between two otherwise identical builds of the same product,
> at the same site.
This reasoning is not cogent. It is the responsibility of site
administrators (or their contractors, or whatever) to establish and
maintain a uniform deployment of OpenAFS servers--or indeed, to be quite
frank, their prerogative to establish and maintain whatever
configuration of OpenAFS servers they darned well like.
>
>
>> which always presents these bits as ABCDEFGH, regardless of what they
>> mean. If you think that's too confusing, I could certainly work up a
>> proposal for protocol extensions to allow clients to discover more
>> descriptive names for these bits, though I have no idea what the UI
>> for 'fs sa' would look like, or what a reasonable implementation in
>> OpenAFS would look like.
>
> Such an extension would remove some of my concerns - but rather than as
> an optional extra, I'd say it's pretty much essential to have it before
> this kind of feature is implemented.
I'm glad you can see your way to this. Perhaps there is an unburdensome
way forward.
>
>
> But the use of these bits isn't incorporated into the OpenAFS code.
> Using site extension bits currently requires that an administrator is
> very aware that they are deploying a local extension, and of the
> ramifications of doing so. Incorporating these extensions into OpenAFS
> normalises their use, and I think that is highly undesirable. In my
> view, the use of site local bits should require site local patches.
You have not established that requiring external patching is the only
effective way to communicate the message
"you should think carefully before enabling this optional feature,
foolish mortal"
to site administrators _custom building OpenAFS from source_.
Here is sound reasoning (fixed that for you):
* building OpenAFS from source carries with it acceptance of the
responsibility for 80% of the consequences
* the OpenAFS gatekeepers carry the remaining 20% of the responsibility
for the consequences, and they may fully discharge it by:
** making OpenAFS build in the safest, most universal configuration for
the supported platform being build, by DEFAULT
** they may discharge an additional 15% (adding up to 115%!) of their
responsiblity to protect users by adding "**DANGER Will Robinson!
Danger!** to the --help output for each terrible feature like the
proposed, which we commit into OpenAFS
>
>>> Unfortunately, the reality is that increasing the complexity of the
>>> OpenAFS build system to support site local patches
>>
>> No one's suggesting increasing the complexity of the build system.
>
> The core problem is that it increases the complexity of building, and
> deploying OpenAFS. You now have to ensure that all of your fileservers
> are built with the same set of options. If they're not, you have to be
> careful of moving volumes around between fileservers. This isn't a huge
> issue when you're just discussing one site-local bit. But, when we've
> got one, why not accept more? And then you really do end up with a
> twisty-turny maze of configuration directives. Building and deploying
> OpenAFS is complicated enough already - let's not make it more so.
I think you should re-read your argument here, it is again, uncogent.
The premise that sites cannot be trusted to coordinate uniform build and
release cycles, such that uniform build configurations, and indeed, a
uniform set of OpenAFS program binaries are in use at each release they
roll out, is simply not credible. It is a false premise. Add to that,
OpenAFS actually _builds releases for them_ following whatever supported
profile it prefers. There is no twisty maze of anything being presented
to users or administrators.
>
>> No, it doesn't ease the testing burden, much. But it _does_ ease the
>> maintenance burden, because it means I don't have to spend days
>> hand-integrating changes before I can even begin testing. As I said,
>> I've been there, and I don't ever want to go back.
>
> If the code is never built, how can you tell that it's still working?
> I've been pushing for a while for a reduction in the number of --enable-
> options, especially for little used code. If we're going to move forward
> into a world where automated regression testing is the norm, this is
> going to be more and more important - we simply won't be able to build,
> let alone test n^2 different configuration sets.
The problem with this argument is that it too is uncogent. We/you/the
gatekeepers do not carry the responsibility to test every feature
OpenAFS can perform, but rather only a vetted list of features which we
choose to support. This is a practical matter, a plain fact. The cause
of honest discussion is not advanced by this silly reductio ad absurdam.
>
>>> In order to add new ACL bit assignments to OpenAFS either the community
>>> needs to revoke the availability of the site local bits or we need to
>>> alter the protocol in order to support a larger number of bits.
>>
>> Or, the community could decide that the proposed approach is just fine.
>
> They could. We've heard from a number of voices against the proposal. It
> would be interesting to hear from people who believe both that
> integrating this patch is a good idea in theory, and who would in
> practice use it at their site. You are arguing that there's no consensus
> against this patch, and that may be true. However, there certainly seems
> to be no consensus for including it at the moment.
As argued above, this argument is not sufficiently persuasive nor
sufficiently strong for its intended use (proscription).
>
> Cheers,
>
> Simon.
>
Regards,
Matt
- --
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
http://linuxbox.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJPp2YJiSUUSaRdSURCJwFAKCS4R0itnCic76ywdoLRX60aoR5+wCgi4ZI
ysgdbROVgejltPRJ9Ui4+Bs=
=LdyD
-----END PGP SIGNATURE-----