-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi List,
After out-of-band communication about the fate of Michael's build-time configurable chown feature, I'd like to re-open the discussion, with a view to addressing more directly the topic of site specific customization of OpenAFS. I find myself leaning to the view that this (ACL mods) is an area in which, historically, there has been site-specific customization, and collaterally, to the view that the cause of OpenAFS is helped more by easing the workload on site administrators who might want this or similar features, than it is harmed by the introduction of subtle differences in ACL behavior within different cells. The primary objection to the build-time configurable version of this patch appears to have been Simon's opinion, shared by at least Derrick: > AFS should be a single, standard system, not some arcane combination > that differs according to the particular configure options which were > selected by each site. Users should be able to expect a consistent > experience across multiple AFS sites, especially for items which they > interact directly with such as ACLs. and (earlier, but amplifying): > Please, please, please don't make this configurable. From a user > experience point of view it's horrific. Having the ACL bit which > controls this behaviour differ between cells (and even between > fileservers) will confuse any user who moves between sites, or even who > reads a different site's documentation when trying to come to grips with > AFS. It spectacularly violates the principle of least surprise. Although I follow this reasoning, I'd at least tender the possibility that the following reasoning is at least equally plausible, disregarding for the moment the current scarcity of ACL bits: 1. it is in fact reasonable for different access control policies to be applied in clearly distinct administrative domains (the definition of an AFS cell); Viewed in that way, it seems quite illogical to invoke "the principle of least surprise" as an argument against site-specific ACL behavior 2. insisting on ACL uniformity across sites is a neologism (some large sites have historically wanted and created local policy in this area, so the conservative position would appear to be, to continue to support it) 3. OpenAFS has an interest in making life easier for site administrators where possible--removing the need for one site-local patch and test cycle may seem like modest savings, but removing the need for several could easily sum up to significantly reduced cost administrative cost Again, I don't have very strong feelings about the feature per se, but I would like to find ways to be more flexible with regard to site specific customization in matters of administrative policy, and to sites' perceived special needs, rather than less. Sorry to belabor this, 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 iD8DBQFJOxPbJiSUUSaRdSURCEMJAJ9mKtoggwvU8GZ5j9mpms6vAJGfXwCgmCj1 HSh17BA2gNmuV2MnUNe+79o= =HgCU -----END PGP SIGNATURE----- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
