admin-how-to

This is a reference for various tasks that admins may have to perform.

create new wiki accounts

Public account creation is currently restricted, so an admin will need to create new accounts when requested.

• In a private message, confirm with the person what their desired username is
• Open Special:CreateAccount
• Enter the desired username and a random password -- use a random password generator like Norton's Password Generator
• In a private message, let the person know the password
• Instruct them to log in and change their password

web server restart

If you're reading this then either the server is up, or the server is down and you're reading a Google Cache copy (thus it's still useful to post this here).

If the web server is down, e.g. someone notes on IRC or Twitter:

• "if any of the microformats.org website admins are on, the site is down."

Then:

• ssh into the server
• check for web server errors (sometimes this can reveal the source of a problem)
  • tail /var/log/apache2/error.log
• find the apache install (it might not be where you expect it or it might have moved)
  • locate apache
• then using the full path to "apachectl" (rather than just "apachectl" in the command)
  • sudo apachectl -k restart
• if you get an error like:
  • (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
• then see if there are any existing stalled restart processes by doing:
  • ps -eaf | grep http
• if you see any processes like:
  • 1337 ? S 0:44 httpd -k restart
  • 31337 ? S 0:44 httpd -k restart
• then kill them using their id (that first number) like:
  • sudo kill -9 1337
• if there are too many to do individually, you can also use:
  • sudo killall -9 httpd
• re-run the ps command:
  • ps -eaf | grep http
• it should be the only thing running with "http" in the name, e.g.
  • 25252 pts/0 S+ 0:00 grep http
• at this point, try restarting the apache server again:
  • sudo apachectl -k restart
• and you should see:
  • httpd not running, trying to start
• now try browsing to http://microformats.org/ and make sure it loads
• report back on IRC or Twitter to whoever pointed out that the server was down.

If you see an error like:

-bash: fork: Cannot allocate memory

or if the server is (still) sluggish to respond, you may need to reboot the entire server (see below, #reboot_entire_server).

semaphore exhaustion

This is a much rarer error state: Apache error log stating: [emerg] (28)No space left on device: Couldn't create accept lock (/etc/httpd/run/accept.lock.NNNN) (5). Thanks to http://rackerhacker.com/2007/08/24/apache-no-space-left-on-device-couldnt-create-accept-lock/ for the hint.

• If the output of sudo ipcs -s is lots of lines of dead apache process IDs leaving semaphores behind:
  • sudo sh
  • for i in `ipcs -s | awk '{print $2}'`; do (ipcrm -s $i); done
• you will see two lines of erroneous output:

• • ipcrm: invalid id (Semaphore)
  • ipcrm: invalid id (semid)

… and then proceed to restart as before.

mail server restart

If sending mail to a list address doesn't seem to send it along (nor appear in the archives), try restarting Mailman:

• ssh into the server and then do:
• sudo /usr/lib/mailman/bin/mailmanctl restart

Last param options are: stop/start/restart

mail server debugging

To check to see if unix permissions are compatible with what Mailman needs, you can:

• ssh into the server and then do:
• sudo /usr/lib/mailman/bin/check_perms -f

The -f reports which directories or binaries had to be changed.

reboot entire server

If the web server is very slow to respond, especially after attempting to restart it as above, then you may need to reboot the entire server.

• ssh into the server, and then do:
• sudo reboot -n

You'll need to close your ssh window and reconnect.

After about 10-15 seconds at most, you should be able to load microformats.org pages as before, and they should load fairly quickly.

check disk space

After rebooting, check disk space in case the server has somehow filled (or is getting close to filling) its disks. From the ssh command line, do:

• df

You should see something like:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vzfs             80000000  15072204  64927796  19% /

Well below 100% usage. If you're seeing something >50%, you might want to look at purging old logs.

irc

Loqi is in the #microformats irc channel and logs to https://chat.indieweb.org/microformats

• If not (either), see https://indieweb.org/Loqi for instructions

Loqi passes along wiki edits to the irc channel as well

• If not, check {server-www-home}/wiki/LocalSettings.php for $wgRC2UDPAddress and make sure it is set to the right host (or IP) (e.g. 'freenode.loqi.me').
  • Log any changes you make (at least locally yourself), so you can revert anything in case something unexpected/unrelated goes wrong, then investigate *after* reverting so people can keep using the site.
  • Changes should take effect immediately after edits to LocalSettings.php are saved (no need to restart MediaWiki or Apache).

wordpress

RSS feed link:

<a href="<?php bloginfo('rss2_url'); ?>" id="footer-feed">RSS Feed</a>

server transition steps

When server transition tests have passed, here are the steps to complete the server transition:

• put up a header message on the wiki like:

  Maintenance Window - All Editing will be disabled. Thursday, April 19, 2012 - 10PM - 1AM Pacific.

  (inspired by https://wiki.mozilla.org/ )
• re-replicate the MySQL as needed for MediaWiki and WordPress
• update any new Mailman settings, archives
• re-do tests on transition server
• flip DNS switches
• ... anything else?

server transition testing

Some things to check when transitioning to / setting up a new server.

editing your local hosts file

In order to test a new server from your local machine and still have hardcoded URL references work, you may need to manually edit your local machine's hosts file, per:

http://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/

• Add the line:

  64.207.154.205 www.microformats.org microformats.org
  

  to the hosts file on your local machine.
• Do the flush cache tip as described below.
• Restart your browser

Your browser should now behave *exactly* as if you'd switched actual DNS.

This makes it a very good way to test.

DNS flush cache tips

If you're using OSX, you'll probably have to run this to flush the local dns cache:

dscacheutil -flushcache

current servers being tested

• http://mt.microformats.org/

home and blog

• home page: http://microformats.org/
• blog permalink: ...
• logging into WordPress: ...

wiki

• wiki home: http://microformats.org/wiki/
• logging in: http://microformats.org/wiki/Special:UserLogin
• logged in wiki home (should just take you there automatically)
• ...

irc bots

• does editing a wiki page result in the bot noticing and outputting the diff to irc://irc.freenode.net/microformats ?

profiles

• http://microformats.org/profile/hcard

media

• audio / video recordings of talks
• ... need URLs ...

mailing list archives

• ...

shorteners

• http://microformats.org/w/hcard should go to http://microformats.org/wiki/hcard
• http://microformats.org/x/hcard#fn should go to http://microformats.org/profile/hcard#fn

other

• ...

transition older pages to public domain

Per Microformats_Wiki:Copyrights, perform the following steps to transition a page created/edited before 2007-12-29 to public domain (pages created after that point are already in the CC0 compatible public domain).

1. verify all editors who contributed substantial content (anything conceivably copyrightable, e.g. minor edits/typos don't matter) have added the {{cc-public-domain-release}} to their User: page per Category:public_domain_license.
2. if you find substantial editors without the cc-public-domain-release, you may choose to at your discretion:
   1. contact the editor to request that they add it to their user page
   2. OR remove the content they contributed
3. add this wiki markup to the bottom of the page:

----

{{cc-pd-license}}

attack logs

Note any logs / summaries of attacks. Anything more than a summary should be moved to its own page.

• 2012-02-01 openlinksw were issue excessive http requests, sufficient to unacceptably increase user access latency. banned an IP.
• 2010-10-31 Banned demo.OpenLinkSW.com by IP, 63.119.36.50 -Rohit
• ...

see also

• admins