On Mon, Jun 13, 2022 at 1:06 PM Chris Lambertus <c...@apache.org> wrote: > > > On Jun 12, 2022, at 4:54 PM, sebb <seb...@gmail.com> wrote: > > > > If the problem is just that recreating ou=meta is messy, then there > > are other solutions. > > > > For example, it should not be too difficult to compare the lists and > > only update those which have changed. > > Probably can also speed this up by comparing last updated dates. > > > > It might also make sense to enhance Whimsy to update the ou=meta list > > at the same time as the owners. > > As Sam points out this would require that the karma needed must agree > > with the karma for owners. > > Yes, this whimsy enhancement is ultimately what my proposal is -- update > whimsy to maintain the pmc groups with instead of having a separate > drop/parse/create system as we do now. I am not sure what you mean by "karma > needed must agree" though. Are you referring to LDAP ACLs? if so, the policy > would already allow this if the ou is under ou=groups.
I preface the following by stating that what I am about to say may be a result of my ignorance of LDAP configuration capabilities, but I believe the crux of the issue can be found on the following line: https://github.com/apache/infrastructure-p6/blob/d0e1160c2a5d0a7f6b91978933333f126f80013f/modules/ldapserver/templates/slapd.conf.erb#L321 What that line says is that (in addition to root, secretary, pmc chairs, and the secretarial team) members of [P]PMCs can edit their own group. So, for example, PMC members (owners) can add/remove committers (members). Now for a thought experiment. If 'owner' is problematic for some tools, then what would an LDAP configuration look like with NO owners? What we would need is the ability to specify "members of groups in this subtree are authorized to write to CORRESPONDING groups in ANOTHER subtree". We have the ability to say that "members of THIS SPECIFIC group can write to THAT SPECIFIC group". And the ability to say "members of THIS SPECIFIC group can update that entire SUBTREE". But as far as I know (and this may very well be my ignorance), there is no way to grant corresponding members of one subtree update access to another subtree. > > This would minimise process changes as well as minimising LDAP updates. > > This is the goal. > > > In case there are Infra scripts that update owners it would make sense > > to keep a regular check on the consistency of the lists. > > Yes, I have been looking to see if there are any infra scripts which would > need to be updated, but I currently believe the only active tooling is within > whimsy. > > -Chris - Sam Ruby > > Sebb > > On Mon, 13 Jun 2022 at 00:32, Sam Ruby <ru...@intertwingly.net> wrote: > >> > >> From a whimsy requirements perspective, the key requirement is that > >> PMC members can update LDAP the PMC (i.e., both the PMC and committers > >> lists). > >> > >> On Sun, Jun 12, 2022 at 6:56 PM sebb <seb...@gmail.com> wrote: > >>> > >>> On Sun, 12 Jun 2022 at 21:26, Chris Lambertus <c...@apache.org> wrote: > >>>> > >>>> > >>>> Hi folks, > >>>> > >>>> I have been working on some updates to the LDAP service, and I would > >>>> like to get rid of ou=meta,ou=groups,dc=apache,dc=org (or at least the > >>>> process which manages it.) > >>>> > >>>> Some history -- this ou was created to address a problem which arose > >>>> after project groups were converted to member/owner (INFRA-16188). The > >>>> Atlassian Crowd service that feeds authentication and authorization for > >>>> Jira and Confluence does not understand the "owner" concept. > >>>> > >>>> Infra had previously created local roles in cwiki and jira, and > >>>> generally pushed maintenance of memberships of said roles to the project > >>>> owners defined within cwiki and jira. Over time this grew cumbersome, > >>>> and we elected to switch to LDAP-based groups, but we only had access > >>>> via Crowd to the attr=member version of the groups, so we could not > >>>> assign PMC-based roles. > >>>> > >>>> Because of this, I created a stop-gap process which drops and reloads > >>>> ou=meta nightly, populating > >>>> ou=$project-pmc,ou=meta,ou=groups,dc=apache,dc=org with attr=member of > >>>> the PMC members. This process is awkward, and causes problems with the > >>>> LDAP audit logging system. > >>>> > >>>> I would like to gather feedback on re-creating and maintaining the > >>>> ou=pmc tree in parallel with the owner/member paradigm that is now in > >>>> place, specifically to support Crowd-based applications (which now also > >>>> include JFrog/artifactory,) or other 3rd party tooling which may not > >>>> understand member/owner. > >>>> > >>>> At this time, I believe the only ASF tooling which creates or modifies > >>>> the owner attribute of project groups is Whimsy, so any code adjustments > >>>> would likely have to happen here. > >>> > >>> AFAIK Whimsy is not the only place where accounts are created and PMC > >>> memberships updated; there are likely some Infra scripts that do so. > >>> > >>> It's not clear to me whether the existing owner attributes will be kept > >>> or not. > >>> Indeed I'm not clear what the proposal is. > >>> > >>>> What are your thoughts? > >>>> > >>>> Thanks, > >>>> Chris > >>>> ASF Infra > >>>> > >>>> >
