> On Jun 15, 2022, at 4:15 PM, sebb <seb...@gmail.com> wrote: > > On Mon, 13 Jun 2022 at 19:12, Chris Lambertus <c...@apache.org > <mailto:c...@apache.org>> wrote:
<snip> >> Does this seem like a reasonable approach? > > It seems quite complicated compared with just fixing the existing > script to generate updates rather than recreating everything. Yes, I believe that is the option I will go with. Thanks for the input. -Chris > >> -Chris >> >> >>> >>>>> 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