A technical suggestion, and a cautionary note. The technical suggestion is that anything that can be done via a cron job can be done by qmail. And you won't have to wait. Take a look at .qmail-__update_forward__ . If you email that address, it will run the generate-dotqmail-availid.py script once the mail is received. Avoid setting things up for ssh, set up the cron job as a redundancy, and take advantage of the ability to kick off scripts by sending an email.
The cautionary note: make sure that the secretary and assistant secretary are able to maintain this tool before deploying the change. They dynamic here is that if the current infra tool breaks, the infra team will fix it. If this moves to the secretary workbench and it breaks, THE INFRA TEAM WILL NOT FIX IT. - Sam Ruby On Thu, May 28, 2020 at 3:47 PM Sebb (Jira) <j...@apache.org> wrote: > > > [ > https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078325#comment-16078325 > ] > > Sebb edited comment on WHIMSY-113 at 5/28/20, 7:46 PM: > ------------------------------------------------------- > > Relevant sources for existing implementation: > > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/make-accounts.sh > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/check-pmc-notifications > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/new-account-reqs.py > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/ap-adduser > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/account-mailer.py > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/account-pmc.ezt > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/account-root.ezt > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/account-welcome.ezt > > Overall flow: > > 1) first step is to check to see if the PMC was previously notified of this > request. Such notifications are done today by the new account request form. > This step may no longer be necessary, replaced by the secretary verifying the > vote link. If it is to be retained, it will require whimsy-vm4 to have ssh > access to an account that can read the mail archives. In fact, this logic > could reuse the existing check-pmc-notifications logic. Note: that logic > doesn't appear to currently handle PMC to mail list mappings (such as whimsy > => whimsical). > > 2) Next the PMC and user names are checked. This logic is already present in > the new account request form. > > 3) Next the email address is enabled on our MX. This will either require > whimsy-vm4 have ssh access to hermes with an account that is capable of > sudo'ing in as apmail. Or this could be done with a new email request > process (file being committed to svn in a directory that is only writable by > the secretary and processed by a cronjob). Or it could be done as a > byproduct of the current cron job that updates .forward files (see step 7 > below). Note that this step bails if the email address is already taken, so > at a minimum, the ability to ssh into hermes into an account with at least > read access to existing .qmail files is required. > > 4) Then the LDAP entry is created, with provisions for generating the initial > password, computing the user and group id, and givenname. This can and > should be expanded, per https://issues.apache.org/jira/browse/INFRA-13850 > > 5) Next the user is added to the relevant project group(s). This will be two > groups in the case of podlings, as the new user will also be added to the > incubator project. > > 6) Next the user's home directory is created. This clearly requires sudo > access. It also presumably is no longer necessary [Later: it is presumably > needed on people/home?]. Somewhat related: the unix group for the person and > some of the LDAP setup can possibly be removed (e.g., gidNumber, > homeDirectory, loginShell, host). [Later: this is still required] > > 7) The email forwarding address is then set. This also may no longer be > necessary? Will need to verify this. I believe that this is set from ldap > by a cronjob. [Later: these are two different items. .forward is set to > uid@a.o - presumably on people.a.o. Hermes runs a cronjob that extracts the > LDAP mail attribute(s) and updates the appropriate .qmail-uid files] > > 8) Emails are send out to root, the pmc and the new user. > > > was (Author: rubys): > Relevant sources for existing implementation: > > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/make-accounts.sh > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/check-pmc-notifications > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/new-account-reqs.py > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/ap-adduser > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/account-mailer.py > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/account-pmc.ezt > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/account-root.ezt > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/account-welcome.ezt > > Overall flow: > > 1) first step is to check to see if the PMC was previously notified of this > request. Such notifications are done today by the new account request form. > This step may no longer be necessary, replaced by the secretary verifying the > vote link. If it is to be retained, it will require whimsy-vm4 to have ssh > access to an account that can read the mail archives. In fact, this logic > could reuse the existing check-pmc-notifications logic. Note: that logic > doesn't appear to currently handle PMC to mail list mappings (such as whimsy > => whimsical). > > 2) Next the PMC and user names are checked. This logic is already present in > the new account request form. > > 3) Next the email address is enabled on our MX. This will either require > whimsy-vm4 have ssh access to hermes with an account that is capable of > sudo'ing in as apmail. Or this could be done with a new email request > process (file being committed to svn in a directory that is only writable by > the secretary and processed by a cronjob). Or it could be done as a > byproduct of the current cron job that updates .forward files (see step 7 > below). Note that this step bails if the email address is already taken, so > at a minimum, the ability to ssh into hermes into an account with at least > read access to existing .qmail files is required. > > 4) Then the LDAP entry is created, with provisions for generating the initial > password, computing the user and group id, and givenname. This can and > should be expanded, per https://issues.apache.org/jira/browse/INFRA-13850 > > 5) Next the user is added to the relevant project group(s). This will be two > groups in the case of podlings, as the new user will also be added to the > incubator project. > > 6) Next the user's home directory is created. This clearly requires sudo > access. It also presumably is no longer necessary. Somewhat related: the > unix group for the person and some of the LDAP setup can possibly be removed > (e.g., gidNumber, homeDirectory, loginShell, host). > > 7) The email forwarding address is then set. This also may no longer be > necessary? Will need to verify this. I believe that this is set from ldap > by a cronjob. > > 8) Emails are send out to root, the pmc and the new user. > > > Have Secretary create new accounts directly > > ------------------------------------------- > > > > Key: WHIMSY-113 > > URL: https://issues.apache.org/jira/browse/WHIMSY-113 > > Project: Whimsy > > Issue Type: New Feature > > Components: SecMail > > Reporter: Sam Ruby > > Assignee: Sam Ruby > > Priority: Major > > > > See also: https://issues.apache.org/jira/browse/INFRA-14456 > > Currently most new account requests are made by the secretary, with the > > remainder by PMC chairs and ASF members. These requests are made by whimsy > > forms and result in a file created in svn that is processed, generally > > daily, by infrastructure staff. > > The new process envisioned is that the secretary will create new accounts > > directly; and that new account requests will be sent via email to > > secretary@ and processed by the secretary workbench. Generally, processing > > of such requests should be at most a few mouse clicks, though an > > opportunity will be provided to tweak such things a public names and to > > verify that a proper vote link was provided. > > > > -- > This message was sent by Atlassian Jira > (v8.3.4#803005)
