You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by sebb <se...@gmail.com> on 2009/05/15 12:19:53 UTC
Re: What a mess - SVN authz vs /etc/groups
On 15/05/2009, Tony Stevenson <to...@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
>
>
>
>
>
>
>
Re: What a mess - SVN authz vs /etc/groups
Posted by Brett Porter <br...@apache.org>.
On 15/05/2009, at 10:47 PM, Tony Stevenson wrote:
>
> 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.
I think this is a good standard, but I'm not sure you need to alter
the current authz file or figure things out for the projects. If they
don't seem to match up, let them know and ask them to sort it out :)
As far as I understand, the POSIX groups (other than the different
ones in first list of your original email) all reflect committership,
not PMC membership, so can be derived without these changes. If you do
want to populate the PMC rosters in LDAP that'd be better coming from
committee-info.txt than svn-authz.
(Apologies if I missed something important as I haven't been following
that closely)
Cheers,
Brett
Re: What a mess - SVN authz vs /etc/groups
Posted by Tony Stevenson <to...@pc-tony.com>.
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 <to...@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
--------------------------------------------