On Thu, May 28, 2020 at 4:56 PM sebb <seb...@gmail.com> wrote: > > On Thu, 28 May 2020 at 21:37, Sam Ruby <ru...@intertwingly.net> wrote: > > > > 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. > > Good point. > > However at least one of the actions must succeed before account > creation can complete. > E.g. setting up the .qmail file for the new user. > If that has not completed, then the email telling them the account has > been created will be lost. > > There would need to be some way to get an ACK/NAK back from qmail. > Perhaps an email, or maybe hermes can push a result file back to Whimsy.
Perhaps hermes could send the email? Note that qmail has access to the body of the email that you sent triggering the request. and it can contain instructions. And you can test this by setting up a .qmail file that sends emails to yourself. But in any case, my concern is from a security perspective. If somebody were to find a way to hack into hermes, the least of my concerns would be that they might be able to leverage that to compromise a whimsy-vm. But the reverse is not true: if somebody were able to hack into a whimsy-vm, I would be very concerned that they might be able to leverage that to compromise hermes. So hermes pushing to whimsy: fine. But whimsy having shell access to hermes would concern me. > > 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. > > If Whimsy breaks, then won't INFRA will have to do all the account set > up themselves? > AFAICT it would be to their advantage to help. My experience differs. Proceed as you feel best. - 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)
