ARLIER THIS month the server running Techrights got migrated and upgraded (from Linux techrights.org 2.6.18-308.el5xen #1 SMP Tue Feb 21 20:47:10 EST 2012 x86_64 x86_64 x86_64 GNU/Linux with 2 cores on CentOS release 5.9 (Final) to Linux techrights.org 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux with 4 cores on CentOS release 6.4 (Final)). Thanks go to Copilotco for providing hosting space and kind support. Here is a look at some of the work involved in this whole process. It can be subdivided into a bunch of tasks as follows:

• Setting up the backup cron job, among other jobs. For the standard user/s this involves just nightly backups of all databases overnight, at around 8 PM East Coast time (the physical server is based in California). For root, the story is a little different. Monitoring is run with E-mail alerts (in addition to third-party services which poll over HTTP and dispatch warnings in Web/E-mail form). Someone wrote a script for automatically restarting Apache and sending some diagnostics around multiple maintainers if the service seems to be malfunctioning. I wonder, however, if we need this to run on the new server by default, considering the fact we might have uptime/continuity of service for months as we did years ago. This used to be run as a cron job, in a line which contains */5 * * * * /usr/local/sbin/web-watch. We will be saving it in the home directory before we decommission the old server and lose data. The scripts associated with the jobs have been copied and given the same permissions as before, so they should be usable. HTTPD restart script (in cron job with correct permissions in associated files) requires some cold testing, with additional cron jobs-related tests (requires lots of testing to prevent major catastrophe, e.g. .htaccess should not be (mis-)configured to permit access to privileged parts of the site (none except system files)).
• Needing to compare DB sizes to assure all data was migrated successfully (about 1.8 GB of text in the databases). This is tricky for a tool like diff to address. Given that the import yielded no warings and the database dump sizes are roughly right (with the newer, active database being slightly larger), this seems to be passing the sanity check. Readers were encouraged to report problems with the site, as well.
• Blocking wiki edits which are anonymous, i.e. from the new address of Varnish. There are Wiki spamming attempts ongoing, and as soon as new registrations and edits by them are allowed, the Wiki gets littered with spam. None of that has stopped.
• Merging of domains is work in progress. In Google, site:http://boycottnovell.com might start showing duplicates (w.r.t. Techrights.org) because access to the former domain does not result in the URL being overwritten/rewritten as Techrights.org. To prevent the search engines’ indexes from filling up for two separate domains, the old behaviour is preferred and should be restored. In short: Needing to check that all domains, two .com domains and the default .org domain, are all merged properly to give one single URL for each page, with no plurality (canonical form). Testing a lot of pages on different kinds of sites/domains, redirections included, e.g. boycottnovell.com/SOME-POST-PATH, helps provide reassurance here (for link integrity, i.e. no 404s, not just SEO-driven).
• Finding the master template for /etc/sudoers, wherever it resides. We need to add a line to sudoers to allow for faster restarting of the IRC bot/s.
• The statistics package we use (needed for security with 4-week retention, but locally-accessible only, for privacy reasons), a simple program called Visitors, has been recompiled for the new server and data passed to /root where scripts reside whose function is retained, having replicated Apache configurations and other settings that relate to them. Some testing is still required for some bots’ function, e.g. access via HTTP to localhost. The Varnish proxy complicates debugging.
• Checking of cache directories and plugins, ensuring that they work and aid performance. Pages should generally be loaded more quickly, owing in part to hardware improvements.
• IRC logs and access to them should be verified (5 years’ worth), along with access to directories through contents listing (blocked by default in some Apache configurations). Seeing errors through logs can help diagnose such issues.
• MIME types for filetypes such as Ogg should be checked, with different file extensions and in-page embedding being tested. A test of oggs seems mostly fine, at least for TechBytes episodes. On the old server (under /etc/mime.types), “video/ogg ogg ogv ogm” was used to capture variations of file extensions. The new server needed OGM added (cat /etc/mime.types | grep ogm showed it to be conspiciously missing).
• Mailing technical details to another privileged user, perhaps getting another public key on the server.
• Magpie RSS in the Wiki for fetching latest stories from WordPress. Currently, this does not work and it did prove problematic in the past, too.
• There are 4 directories of Patent Troll Tracker posts which need to be made inaccessible (chmod 000 for instance) as the author asked them to be made invisible (he got sued over it) before we made the mirror. This is needed for offline preservation (information about notorious patent trolls).
• Needing to recheck root directories for similarities, ensuring nothing valuable is left behind on the decommissioned server. This can be achieved most simply using a count of files in several locations, checking space used in areas of importance.
• Directory listings, e.g. listing of court exhibits, should be enabled despite the default paranoid setting in Apache. Alternative domain names will inherit those same rules if properly set up.
• Resorting a regular remote backup routine, e.g. through the gateway or from server directly to desktop (in the UK), in addition to backups near the rack.

 Add your comment(s) |  Send this to a friend

This entry was posted on Sunday, June 16th, 2013 at 12:53 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.