Perl Mongers

208 international Perl User Groups.

Welcome! This page intends to house all the information admins need to maintain pm.org services. Suggested improvements welcome via GitHub

Intro: How does *.pm.org work?

Robert and Ask are the server kings. They control all the hardware and services. They keep the ships afloat.

When anyone needs help with anything Perl Mongers they create a github Issue or they email support(at)pm(dot)org which opens a ticket in RT. Some requests are valid, some are bad ideas or conflicts between group leaders, and some are spam. Those tickets need to be waded through, as frequently as possible, by the pm.org admin volunteers. Everything there is to know about being a pm.org admin volunteer is right here, below.

Working the tickets involves pulling miscellaneous levers to fulfill the valid requests (XML, git, MailMan, DNS, RT, TT site flushes, lat/long XML for Google map, etc.). I (jhannah) am happy to train new volunteers.

Every communication we have with anyone around the world is recorded in github or RT for review. Constructive criticism is always welcome.

Current Admins

Procedures

Add a Group

  1. perl_mongers.xml
    1. Search to make sure the group didn't exist in a previous life.
      1. If you find the group, change their status to "active" and update all the info.
      2. If you don't find the group, add a new XML block, copying an existing active group and changing all the info.
      3. git: commit and push your changes
  2. DNS for their website
    1. Create an RT ticket in the DNS queue requesting Groupname.pm.org be pointed to their server IP (A record) or hostname (CNAME). e.g.: 
                To: dns@perl.org
          Subject: paderborn.pm.org -> 216.52.237.133
          New PM group. Thanks!
  3. Mailman. If they want a Mailman list (and one doesn't exist already), create one named "Groupname-pm".
  4. Add the tsar to the pm_groups@pm.org MailMan list.
  5. Send a "Welcome!" new group announcement email to pm_groups@pm.org
    1. e.g. http://mail.pm.org/mailman/private/pm_groups/2005-March/000720.html

Modify a Group

Group Leader ("Tsar") Changes

  1. Update perl_mongers.xml
    1. Did their group status change? From "sleeping" to "active" for instance?
  2. Commit, push your change to github
  3. Website changes may require:
    • If we were/are going to host: WebDAV https://groups.pm.org/admin/config/groupfile — change/remove/add?
    • If they were/are going to host: Submit DNS changes?
  4. Update the pm_groups MailMan list. (e.g. remove the old group leader and add the new leader)
  5. Follow the instructions below to change their MailMan password?
  6. Update the website per README

Forgot my Password

  1. Ensure that the MailMan list is owned by the correct person
  2. Change the MailMan password
  3. Email group leader telling them that their password has been changed to the value listed in the other email

Remove a Group

  1. Mark group as inactive in XML file
  2. commit, push changes to github
  3. Refresh www.pm.org (see https://github.com/perlorg/www.pm.org/blob/master/README)

Web Update

See https://github.com/perlorg/www.pm.org/blob/master/README

Resources

git

https://github.com/perlorg/www.pm.org

MailMan

  1. Admin mailing list
  2. Group Leader mailing list
  3. Group lists
  4. Timestamps when lists last saw activity — some of which are old
  5. Create a new list
  6. Remove a group - you need a shell to run rmlist, so if you don't have one email pm_admins(at)pm(dot)org
  7. super-duper password — admin any group's config

Cron jobs run every 20 minutes or so to implement any new groups you add.

Request Tracker (RT)

http://rt.perl.org/rt3/ (queue: pm-org-support)

Group leaders open a new support ticket by sending an email to any of these equivalent addresses:

  • support(at)pm(dot)org
  • tech(at)pm(dot)org
  • bugs-pm-org-support(at)rt(dot)perl(dot)org

DNS

In order to get a DNS change to happen, send an email to dns(at)perl(dot)org with information about the change you want made. You'll get an auto-reply ticket number back from RT. Things they do:

  • A records - we will point them at groups.pm.org(216.52.237.133) or their server.
  • MX records - usually point at mx.develooper.com.
    • Note: MX records cannot point to CNAMES. This makes some mailservers unhappy
  • CNAME records - sometimes this is easier than an A record

We can also provide NS records (aka delegation) of foo.pm.org to other nameservers.

For established groups....

  • AAAA records (IPV6)
  • special things like SRV records and more A records.

Sample Message


 To:        dns@perl.org
 Subject:   aberdeen.pm.org -> 216.52.237.133
 
 New Perl Monger group. Thanks!

XML

https://github.com/perlorg/www.pm.org/blob/master/perl_mongers.xml

All pm.org services are (or should be) driven by our single, master XML file. That file is perl_mongers.xml. The format is defined by perl_mongers.dtd (out of date). When the .xml is updated, programs read the .xml and write that info out to www/groups.

The "status" attribute

Q: What does a status mlb or leb mean?

A: Dave Cross, November 2004: These are left over from when I was tracking down all of the groups in 2002. I emailed all of the group leaders to check if the group still existed. "leb" stands for "leaders email bouncing". In some cases I then went on to try and email the group's mailing list. "mlb" stands for "mailing list bouncing". I should probably change all of those statuses to "inactive" now.

Q: Is there a difference between inactive and sleeping?

A: Dave Cross, November 2004: Inactive means that the group is basically dead. There's no interest in keeping the group going. I keep the records around because someone might come along in the future.

Sleeping means that there are one or two people who want to keep the group running, but they are having trouble finding recruits. The main difference is that the xml program generates listing pages for groups with a status of "active" or "sleeping" - but not for "inactive".

Q: If status is not present, does that mean inactive?

A: Dave Cross, November 2004: Yep.

How to be a ticket ninja

So you want to be as super-awesome as me? -grin- Here's how I get my ticket fighting mojo on.
--jhannah, 12:37, 19 July 2008 (UTC)

Firefox

You use the hell out of your web browser fighting tickets. I open a single Firefox window, and then open many tabs that I can click back and forth in as needed. My tab list:

  • In RT, click the pm-org-support queue. You now have a list of all items you need to work. This is especially helpful if you click Preferences | Search options | and add LastUpdatedRelative and LastUpdatedBy to your Show Columns. This way at a glance you can see the ones where an admin last updated the ticket (probably waiting on requestor) vs. the ones where a requestor last updated the ticket (probably waiting on an admin) and how long it has been since the last update. 2 weeks is my "No response, closing ticket" deadline. (You have to set that deadline somewhere. -grin-)
  • This admin page. Specifically the Mailman section. You'll occasionally launch these links into new tabs.
  • MailMan super-duper password. You'll keep copying from here and pasting into other MailMan tabs.
  • MailMan group leaders list | Admin interface | Membership Management | Mass Subscription / Mass Removal. You'll keep clicking back and forth between Subscription and Removal to manage group tsar changes.
  • End of a ticket run: www.pm.org to check site flushes and if they stuck or not.
  • The specific ticket you're working on in Reply mode. Typing your response here.
  • The specific ticket you're working on in Display mode. Looking at the request, as you will forget bits and pieces and need to double-check your work.

So I basically run those 5-7 tabs constantly. The last two keep closing and being re-opened for each new ticket I start work on. Overall the tabs save me a ton of time, as all those resources I use ticket after ticket after ticket are already up and ready.

Terminal.app (or putty, whatever)

I use OS X, so I have 2-3 Terminals running all the time, accessing my local machine.

Terminal 1''' sits inside perl_mongers.xml, changing it with vi. Setting this up the first time goes like this:

Terminal.app
mkdir src
cd src
svn co https://svn.perl.org/pm-admin/trunk perlmongers
cd perlmongers
ln -s /Volumes/admin/groups/www www
vi perl_mongers.xml

The symbolic link above does its magic once the WebDAV below is mounted, allowing you to run bin/xml to magically update the server.

Terminal 2 sits inside the admin WebDAV mount. Launching it looks like this:

Finder | Go | Connect To Server... | https://groups.pm.org/admin/
Terminal.app
cd /Volumes/admin/config
vi groupfile   (and other config files)

Terminal 3 just kind of sits on my local computer doing DNS lookups. Checking if people's DNS change requests are valid / working and what-not.

Mail.app (or whatever email client)

To launch emails to dns(at)perl(dot)org requesting DNS changes. I also glance through the emails from RT, but tend to read and update the tickets online instead of via email.

A typical ticket run

So once in a blue moon (shame on me) when I sit down to pound tickets here's what I do:

  1. Launch up Firefox and all the tabs listed above.
  2. Launch Terminal.app and the 3 windows listed above, including mounting /admin via WebDAV.
  3. cd src/perlmongers; svn update
  4. Pound tickets like crazy. Keep a list of group IDs to which changes have occured along the way. vi perl_mongers.xml until it begs for mercy.
  5. svn commit
  6. Using my list of group IDs (above), I need to delete all those group pages so that bin/xml will create new ones. (It doesn't overwrite existing files. (A speed optimization?)). So cd www/groups; rm 117.html 119.html 343.html ...
  7. perl bin/xml
  8. cp perl_mongers.xml www/groups/perl_mongers.xml
  9. Respond (or fail to respond) to any misc. emails that have trickled in.
  10. drink heavily :)
Congrats! You're a certified ticket ninja! Use your awesome powers only for good. :)
--jhannah 13:07, 19 July 2008 (UTC)