www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Stevenson <t...@pc-tony.com>
Subject Re: What a mess - SVN authz vs /etc/groups
Date Fri, 15 May 2009 12:47:02 GMT

Sebb,

We have decided to use the svn-authz file as the definitive source of  
groups, as the posix groups are somewhat behind (as PMC chairs don't  
have karma to edit them).  This wont be an issue with LDAP as we will  
only have one source of group information  :-)
So with this, we may have some issues with group membership, which we  
will most likely need resolving manually.

There are very few, in fact I cant think of any off hand which exist  
as POSIX groups only (system groups such as wheel etc aside).  However  
there is a bunch of SVN only groups such as infrastructure-interest.

I am trying to remove SVN groups with -pmc that dont protect any /pmc/  
folders and do not have a POSIX group that matches.

This is in preparation for what I hope to introduce as a new standard,  
i.e. 2 groups as per below.



Cheers,
Tony


On 15 May 2009, at 11:19, sebb wrote:

> On 15/05/2009, Tony Stevenson <tony@pc-tony.com> wrote:
>> Right,
>>
>> After manually fudging through both the authz file, and the /etc/ 
>> groups -
>> It looks like this may not be as simple as I had first hoped.
>>
>> As Sebb highlighted yesterday with the Tomcat-PMC group, it could  
>> quite
>> possibly be renamed to tomcat. Indeed it could, and that would be  
>> fine.
>> However a bunch of other projects have a -pmc group also, to  
>> control access
>> to  /pmc/proejctx  - BUT - Not all projects.  One such example is  
>> httpd.
>
> Another is incubator, who have /incubator/private
>
> Not sure why it should matter if a group is missing; seems to me it's
> more important to be able to align the existing SVN and POSIX groups
> somehow. This is quite a problem, as I discovered when I tried to
> validate svn-auth against /etc/groups.
>
> Not all SVN groups have POSIX groups, and not all POSIX groups
> correspond to SVN groups.
>
> Furthermore, when both groups exist, they don't always have the same
> name, and there is not always a 1-1 mapping between them.
>
> Here are the preliminary findings I came up with.
> [Expressed as Perl, but should be easy to follow]
>
> my %unixOnly=(# Groups only used in Unix
>    'apconf'    =>1,
>    'apcvs'     =>1,
>    'apmirror'  =>1,
>    'apsearch'  =>1,
>    'apsiteuu'  =>1,
>    'apwiki'    =>1,
>    'concom'    =>1,
>    'dnsadmin'  =>1,
>    'operator'  =>1,
>    'votetest'  =>1,
>    'wheel'     =>1,
>    'httpdadmin'=>1,
>    'java'      =>1,
>    'jserv'     =>1,
>    'labs'      =>1,
>    'perlwww'   =>1,
>    'santuario' =>1,
>    'servlets'  =>1,
>    'tclwww'    =>1,
> );
>
> my %SVNOnly=(# Groups only used in SVN
>    'apachecon' =>1,
>    'audit'     =>1,
>    'avalon'    =>1,
>    'legal'     =>1,
>    'pmc-chairs'=>1,
>    'staff'     =>1,
>    'svnadmins' =>1,
> );
>
> my %Unix2SVN=(# map Posix names to SVN names
>    'member'  => 'members',
>    'hc'      => 'httpcomponents',
> #    'hadoop'  => 'hadoop-core',
> #    'tomcat'  => 'tomcat-pmc',
> );
>
> my %SVN2Unix=(# map SVN names to POSIX
>    'derby'     => 'db',
>    'mahout'    => 'lucene',
>    'nutch'     => 'lucene',
>    'solr'      => 'lucene',
> );
>
> I'm not sure exactly what all the POSIX groups are used for, so I
> don't know if each SVN name needs a POSIX group or not.
>
>> So my point is this. There is no standard (no surprise from organic  
>> growth
>> really) so now, is the time to ensure we setup a standard.
>
> Hopefully this will be: Document, then implement.
>
>> So I am proposing the following:
>>
>>
>> Each TLP, will have at least SVN groups.
>>
>> 1 -  ProjectX = membera,memberb,memberc etc
>> 2 -  ProjectX-PMC = membera,memberc
>>
>
> +1 (mostly)
>
> But for large TLPs with sub-projects, it will be easier to manage if
> the ProjectX group can consist of subgroups. Such subgroups are needed
> anyway for other purposes.
>
>> This way we can ensure that every project has the same structure in  
>> LDAP,
>> and will allow us to much more easily stick to a standard in the  
>> future.
>
> If it is documented ;-)
>
>> This is of course, assuming we want to stick with /pmc/projectx
>>
>>
>>
>> So going forward to ease the pain of moving to LDAP, and to  
>> introduce a
>> standard we have 2 options.
>>
>> 1)  Flatten out /pmc/    -  Seems like a big hammer approach, and  
>> they may
>> have a valid use.
>
> What do you mean by "flatten out"?
>
> The files in the /pmc/ directories are usually not for general  
> consumption.
>
>> 2)  Add a ProjectX-PMC   -  Ezch project would have min 2 groups.
>> ProjectX, and ProjectX-PMC. The latter used to control access to
>> /pmc/projectx
>
> Sounds better, but one might need to move the incubator/private
> directory. This should cause too much of a problem compared with
> moving a publicly accessible directory
>
> The /pmc top-level directory is protected against general access, so
> it's safe to add new subdirectories.
>
>>
>>
>> Cheers,
>> Tony
>>
>>
>>
>>
>>
>>
>>




Cheers,
Tony


--------------------------------------------
Tony Stevenson

tony@pc-tony.com - pctony@apache.org
pctony@freenode.net - tony@caret.cam.ac.uk

http://blog.pc-tony.com

1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66
--------------------------------------------






Mime
View raw message