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’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