You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Tony Stevenson <to...@pc-tony.com> on 2009/05/15 11:39:28 UTC
What a mess - SVN authz vs /etc/groups
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.
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.
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
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.
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.
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
Cheers,
Tony
Re: What a mess - SVN authz vs /etc/groups
Posted by Martin Cooper <ma...@apache.org>.
On Fri, May 15, 2009 at 2:39 AM, 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.
>
> 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.
There is no standard with respect to whether a project equates each of its
committers to a PMC member or maintains a PMC that is a subset of project
committers. It is up to each project to decide how to manage that, which is
perfectly fine. It makes sense to me that a project using the latter
structure be able to manage karma for the PMC. It doesn't make sense to me
to impose two lists for a project using the former structure.
--
Martin Cooper
>
> 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
>
>
> 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.
>
> 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.
> 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
>
>
>
> 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
--------------------------------------------
Re: What a mess - SVN authz vs /etc/groups
Posted by sebb <se...@gmail.com>.
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
>
>
>
>
>
>
>