Site Specific ACL Bits/chown: Was: [OpenAFS-devel] posix chown
again
Matt Benjamin
matt@linuxbox.com
Tue, 09 Dec 2008 13:41:20 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Simon,
Simon Wilkinson wrote:
>
>
> Your analogy is flawed. No matter how many notes Mozart used, it was
> still possible to determine the quality of the resulting work.
This is rather neat, but in the conceit, he used too many for one
person's taste, in a specific work.
>
> To be clear, I'm not attacking the addition of new features - I'm all in
> favour of them! What I'm against is the addition of code _particularly
> on the stable branch_ which is hidden behind arcane combinations of
> build time configuration switches. (Run time configuration switches are
> a slightly different matter). But the configuration switch issue is
> really just a symptom of why this patch is flawed, rather than the cause.
Ok.
>
>> 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.
>
> Ok. So there's a major philosophical argument here. Why would OpenAFS
> ship code that it doesn't support? If the code isn't supported at all,
> doesn't it belong in some kind of 'contrib' area, rather than in the
> main build. I think there's an assumption that everything in the OpenAFS
> tarball is supported, as much as any of OpenAFS is supported. As far as
> I'm aware, we're not currently listing a set of options that gives you a
> supported build, and declaring 'here be dragons' for everything else.
> However this is really beside the point - the patch isn't flawed because
> it adds yet-another-configuration switch, but because it does so without
> regards for the consequences of making this option configurable.
I agree, this is actually an important discussion to have at greater
length, in some context.
I think we should, perhaps, effectively be doing the
supported/unsupported thing. I think there's room for and precedent for
there being things we support more, and support less, without external
patching. Because drawing the line is hard, I was probably special
pleading myself.
I agree this is quite distinct from the merits, or lack, of the specific
feature.
>
> My argument, as I've made before, is that the solution presented by the
> patch we're currently discussing is neither sensible, flexible nor the
> best available.
Yes, sorry, I was trying to refer to the "we must test all combinations
reasoning" not the ACL bits feature.
>
> *) A user with a presence in multiple sites has to remember what each
> site local bit means in each site. Forgetting this meaning may lead to
> them setting permissions on their files which they didn't intend.
> *) Systems staff building OpenAFS across a large environment must ensure
> that every fileserver build has the same set of configuration options. A
> failure to do so means that ACLs will silently change meaning when a
> volume is moved between servers
> *) Systems staff upgrading OpenAFS must ensure that the new build is
> done with the same options as the last one. Failing to do so will cause
> ACLs to silently change meaning upon upgrade.
>
> In my opinion, an acceptable patch would have to address these 3 issues.
> I think it could do so by adding a mapping RPC, similar to what Derrick
> has already discussed to solve the first issue, and by having the
> ability to detect, and warn of, the latter 2 cases.
Issue 1 indeed seems intrinsic to dealing with the ACL bits feature.
Issues 2 and 3 seem--very different? Again, let's say that the way we
ensure the correct set of build options is used by suggesting that users
deploy OpenAFS-provided builds where possible, and suggest detailed
guidelines for site administrators and external port maintainers, where
it isn't. Of course, I suppose we actually could introduce mechanisms
which warn of inconsistent configuration of programs deployed in the
cell--is that something you were suggesting?
> I think your experience of the world has been a little more cosy than
> mine. I can think of many sites that don't coordinate releases in this
> way. They probably should, but they don't, and that's the world in which
> we have to operate.
I was being hyperbolic, but, I think I actually meant what I said. Site
administrators, &c, need to be responsible for coordinating releases,
particularly if they're going to build the product from source. I know
very well that the world works differently, it certainly does at my
site, I run OpenAFS 1.3.80. But I'm not sure how much weight to give
the obligation to prevent foot shooting, in general, there are a lot of
things we can be doing besides reducing conditional build options to
reduce its incidence.
>
> S.
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
- --
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
iD8DBQFJPrvQJiSUUSaRdSURCC8DAJ0X4Lrz57L6y9jc/stE6y4WRDsu6QCfRh4o
kmWtKNijDsURK9qFwTdJdmc=
=ftFZ
-----END PGP SIGNATURE-----