admin-how-to: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(→‎reboot entire server: check disk space)
(→‎web server restart: update location of error log)
Line 13: Line 13:
* ssh into the server
* ssh into the server
* check for web server errors (sometimes this can reveal the source of a problem)
* check for web server errors (sometimes this can reveal the source of a problem)
** <code>tail /var/log/httpd/error_log</code>
** <code>tail /var/log/apache2/error.log</code>
* find the apache install (it might not be where you expect it or it might have moved)
* find the apache install (it might not be where you expect it or it might have moved)
** <code>locate apache</code>
** <code>locate apache</code>

Revision as of 22:03, 16 October 2012

<entry-title>admin how-to</entry-title>

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

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.

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.

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

home and blog

wiki

irc bots

profiles

media

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

mailing list archives

  • ...

shorteners

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