Small linux deployments

My goals for upgrading to PHP 5 are to do it without breaking any customer websites, and also to use few or no legacy options. Hopefully by being strict about legacy options I can prevent pidgin-php that requires a combination of current and depreciated features, as that would make the upgrade to PHP 6 much more of a nightmare. Specifically url_fopen and register_globals will be turned off, and zend v1 compatibility mode will not be turned on. I have decided to leave register_long_arrays on, because of the sheer number of scripts that use $HTTP_*_VARS style formatting, and because there isn’t much harm in that syntax being available. Register_long_vars will be removed from php 6, but I’m willing to deal with that problem when we start looking at PHP 6 (fortunately, a file search to find all of the scripts using that syntax will be trivial).

Because of these substantial changes, I need a way for my customers to preview their websites rendered by the new php, so we can both be confident that when it comes time to flip the switch there won’t be any issues. I’ve done this by installing a new php and apache on an alternate port, and we’ll be emailing customers shortly to have them check their websites on the alternate port to verify they work correctly, and to make support available to customers who aren’t sure about how to fix their pages ( I actually anticipate very few will call).

I’d like to be able to include links that are not pages in my pages menu, as most themes display the pages menu as the main navigation bar for the site. The general wisdom has been to hard-code those links into the theme, however I want to be able to intersperse links
with pages, and I want to be able to switch themes without patching all of the themes I use.

I accomplished this with a plugin that takes an array of html to insert at points in the pages menu. For example, in my blog I have a link for “computers” and a link for “other thoughts”, which are before any of the real pages are displayed. The configuration line of my plugin looks like the following:

12. //An array of items to insert. 0 makes it the first link, 2 makes the link appear after link 2, etc.
13. $insert_array = array (
14. 0 => '<li><a href="http://erek.blumenthals.com/blog/category/linux" title="linux">Computers</a></li>',
15. 1 => '<li><a href="http://erek.blumenthals.com/blog/category/other" title="other">Other Thoughts</a></li>'
16. Download this code: addlinksaspages.php

To install this in your blog: download the file, customize the insert array with the links you’d like to add, drop the php file in your wp-content/plugins folder, and activate the plugin. Please drop me a line if you decide to use it, as I’m curious what people will do with it. Also feel free to shoot suggestions my way for improvements.

I’ve always been wary of automatic updates. Certainly, they give you the quickest response time, but at the price of stability. I’d rather know exactly what I’m updating when I’m updating it, so if I run into an issue it’s easier to backtrack where it came from. I find that a happy medium is email notification when updates become available. Since most of my servers are running the same distribution, I fire up clusterssh and update them all at once.

Here’s my yum email notification script (adapted from a script by Michael Heiming):

1. #!/bin/sh
2. maila="email@address.com"
3. yumdat="/tmp/yum-check-update.$$"
4. yumb="/usr/bin/yum"
5. CHECKWRK='no'
6. #rm -f ${yumdat%%[0-9]*}*
7.  
8. $yumb check-update >& $yumdat
9.  
10. yumstatus="$?"
11.  
12. case $yumstatus in
13. 100)
14. cat $yumdat |\
15. mail -s "Alert ${HOSTNAME} updates available!" $maila
16. exit 0
17. ;;
18. 0)
19. # Only send mail if debug is turned on
20. if [ ${CHECKWRK} = "yes" ];then
21. cat $yumdat |\
22. mail -s "Yum ${HOSTNAME} no patches available." $maila
23. fi
24. exit 0
25. ;;
26. *)
27. # Unexpected yum return status
28. (echo "Undefined, yum return status: ${yumstatus}" && \
29. [ -e "${yumdat}" ] && cat "${yumdat}" )|\
30. mail -s "Alert ${HOSTNAME} problems running yum." $maila
31. esac
32.  
33. # clean up
34.  
35. [ -e "${yumdat}" ] && rm ${yumdat}
36. Download this code: yumcheckupdates.cron

One more thing is that it’s easy to forget to reboot after a kernel update, or put off rebooting because the time you update the RPMs isn’t the best time to update the kernel. To make sure that I do reboot, I’ve written added an email notification script that lets me know when the latest installed kernel is newer than the currently running kernel:

1. #!/bin/sh
2. CONTACTADDR=email@domain.com
3. LATESTKERNEL=`rpm -q kernel |tail -n1|sed -e 's/kernel-//'`
4. if uname -a | grep -qv $LATESTKERNEL; then
5. echo "Running Kernel is" `uname -r` "but latest installed rpm is ${LATESTKERNEL}" |\
6. mail -s "${HOSTNAME} Reboot required" $CONTACTADDR
7. fi;
8. Download this code: check-kernel.cron

I’ll admit it. Like many other hosting companies, we’ve been remiss in upgrading to PHP 5 on our shared hosting servers. Apparently, we’re in good company. Nexen Services queried approximately 2 million servers and found the following (as of November 2007):

There may be some valid reasons for sticking with PHP 4, especially in highly controlled environments (think Yahoo), or in redistributable software, where you need to be able to reach the largest installed base without requiring architecture changes. However, as a web host to customers in non-controlled environments, and a developer who develops primarily within our own hosting environment, we have the luxury of being a cautious leader.

Also, I think that part of the reluctance to switch to PHP-5 is a fear of the new coding styles that it strongly encourages. The days of <?php include(’header.inc’) ?> are coming to an end, and are being replaced with MVC-esque coding structures. The general PHP community is taking time to come to terms with this.

It’s funny how realization of the need for change often comes out of a personal inconvenience. Last week I set out to write a substantial application to use on our hosting servers, developing it on my personal development box. I uploaded the code expectantly, and found that nothing worked. I had forgotten that PHP 4 lacks many of the magic object methods I’ve grown accustomed to using (__get, and __set, and __construct primarily).

I can either spend a day refactoring my code to work on PHP 4 (and make it much less elegant in the process) or I can take the plunge and get the ball rolling to upgrade all of our boxes to PHP 5. I’m going with the latter option. Implementation details to follow.

I’m a sysadmin and programmer for a local web development and hosting company out of Olean, NY.  We handle many smalltown technology needs, and also a few more complex projects. 

We maintain an internally-developed CMS for use on small to medium websites, with the design goal of absolute simplicity combined with a powerful enough featureset to handle smallscale needs.  I’m currently in the midst of a complete rewriting project, to replace wikimarkup-based editing with WYSIWIG editing, simple database functionality (Think searchable used car listings, job listings, news releases, web-form submission handling, etc.), better modularity, and a unified code base for all of our customers.

 The goal of this blog will be to talk about common sense ways to look at administering small deployments.  It won’t necessarily be about the latest technologies, or the newest fads in technology development, just things that have worked for me to keep things running smoothly.