1. Meta

Date: Sunday, November 18, 2007

Time: 19:00 UTC

Type: Admin-only

2. Agenda

2.1. Joining HCoop procedure

2.1.1. Initial ideas

NOTE: Outdated. Move on to the next section for the current instructions.

Re-opening membership requires a few more fine-tunings of our social processes. The following need to work, though they've not been tested in a while:

• Prospective members apply on the web via SSL. They get to choose username.

• They get a randomly-generated password. Save a copy to /var/lib/portal/passwords/$USER.

• A majority of board members approve their applications.
• They get an automated e-mail with instructions on what to do next.
• They make a payment.
• Their initial payment is processed.

• An admin runs create-user $USER.

  • This gets password from /var/lib/portal/passwords/$USER and deletes the file.

  • Create .forward file? Would need to get their email address somehow, and whether they indicated that they want this on web form.
  • User should be automatically subscribed to hcoop-announce mailing list, in the case that they provided an email address.

Once we figure this out, we can re-open membership.

2.1.2. What we decided on for the account creation process

• Someone applies via https://join.hcoop.net/

  • In case it wasn't obvious above, we're switching it to SSL.

  • The portal generates a random password, stores it with the user's application, and shows it to him. He must remember it until the application process is over.
• A majority of board members approve the application on the portal.
• Some designated person clicks a button on the portal to approve the application.

  • This sends an e-mail to the applicant that contains a link to MemberManual/GettingStarted/NewMember.

• The applicant pays via PayPal or Google Checkout

  • An admin receives an e-mail from that payment service saying that the payment has been received.

  • That admin uses a feature to be added to the portal, which matches a PayPal/Google Checkout e-mail address with an application.

  • That admin uses the portal to create the user.
    • The portal does as much as it can within its own database.
    • It also prints a single command-line something like this to be run on deleuze:

      magic-create-user-wrapper $USERNAME $REALNAME $EMAIL

      These all come from the application database. $EMAIL is optional. If present, it should be used to initialize the new member's ~/.forward file. The new user's password should be read from deleuze:/var/lib/portal/$USERNAME, and that file should be deleted after the account is created.

  • After this is done, the portal sends an e-mail to the new member linking to MemberManual/GettingStarted/AccountCreated.

  • The treasurer is Cc'd on that e-mail and adds the initial payment to the new member's financial history.

2.2. DNS

• Go with http://worldwidedns.net for backup DNS?

  • Yes. MichaelOlson wants to go with the 5 zones plan (or if the plan can be changed at any time, start with two, and then add more as needed).

  • Post-meeting: Not now -- we will be using megacz.com until we can get an actual outside machine to run stuff on.

• When do we want to migrate DNS for domain hcoop.net?

  • MichaelOlson thinks we should do this after forced migration ends, to minimize the possibility of member uncertainty while migrating.

  • Still discussing tinydns v. bind, over the preferred medium of email rather than IRC.

    • Post-meeting: Using tinydns for hcoop.net domain, bind for everything else.

Procedure proposed by Adam Megacz:

1. Make sure NO DNS SERVER is running on deleuze or other (port 53 closed)
2. Create ns5.hcoop.net and ns6.hcoop.net, point them at deleuze+other
3. Add ns5.hcoop.net and ns6.hcoop.net to the root servers
4. Wait 48 hours
5. Simultaneously:
   • shut down tinydns on fyodor
   • shut down tinydns on krunk
   • start bind on deleuze
   • start bind on other
6. Confirm that everything is happy; if not, revert #5
7. Wait a week
8. Remove ns[1-4].hcoop.net from the root servers

The important part about this is that every potentially problematic step (mostly #6) can be reverted instantaneously.

2.3. New Machine Readiness

• AdamChlipala has finished his non-wishlist items for Domtool.

• MichaelOlson finished Mailman stuff, needs to double-check new Domtool Mailman directives and write them up in manual.

  • Post-meeting: This is done.

• Abulafia?

  • Bug: https://bugzilla.hcoop.net/show_bug.cgi?id=168

  • Waiting until after forced migration.
• IPKVM?

  • Bug: https://bugzilla.hcoop.net/show_bug.cgi?id=176

  • AdamMegacz says no deadline, but we will wish we had at some point.

  • Particulars being worked out on the bug report.

Last migration things:

• Exim auth. MichaelOlson will try to finish this off tonight.

  • Post-meeting: Done.

• Jabber. Clinton starts on this on Monday.
  • Should not block migration -- can be done within the month.

2.4. Bugzilla/email

• Need to remove admins AT hcoop.net from Cc: to avoid annoying duplicates.

  • Removed from all default settings now.
  • Admins should add themselves to whichever components they want notifications.

• Send portal emails to addresses other than admins AT hcoop?

  • Needs aliases?
  • Making a new portal AT hcoop alias with just those interested in portal stuff.

    • Post-meeting: Done.