Sams Teach Yourself PHP, MySQL and Apache All in One (2012)
Part VI. Administration and Fine-Tuning
Chapter 32. Performing Software Upgrades
In this chapter, you learn the following:
• How to keep up-to-date with new software releases
• How to upgrade between minor versions of MySQL
• How to upgrade between minor versions of Apache
• How to upgrade between minor versions of PHP
Throughout this book, you have been reminded to seek out information about new versions of PHP, Apache, and MySQL, and to be mindful of updates. Also, you have been shown how to add functionality to PHP at build time, but only in the context of installing the software. In this short chapter, you learn how to update your already installed software over the normal course of time, without wreaking havoc on your system.
Staying in the Loop
You should already have bookmarked the websites for Apache, PHP, and MySQL. It doesn’t matter whether you have been using these technologies for 6 days or 6 years; there will always be a need to refer back to the sites. (I do, all the time!) If the primary reason for visiting the websites is to obtain information about updates, you could always subscribe to an announcements-only mailing list:
• For PHP announcements, go to http://www.php.net/mailing-lists.php and subscribe to the Announcements list.
• For MySQL announcements, go to http://lists.mysql.com/ and subscribe to the MySQL Announcements list.
• For Apache announcements, go to http://www.apache.org/foundation/mailinglists.html and subscribe to the Apache News and Announcements list.
When to Upgrade
As indicated in Part I, “Getting Up and Running” (the installation chapters), revision and minor version changes occur whenever the developers find it necessary to do so—not on any particular schedule. But just because a minor version change has occurred, that doesn’t necessarily mean you should run right out and upgrade your software. Sometimes, however, you should upgrade as soon as possible.
Software releases typically adhere to the format major.minor.revision; for example, PHP 5.4.0 would be major version 5, minor version 4, revision 0. It is true that changes in revisions may be “minor” in nature, but the release is referred to as a revision.
The primary instance in which you should immediately upgrade your software is when a security fix is announced. Usually, security issues are not discovered until they are exploited—sometimes in a testing environment, but sometimes by a rogue user who just wants to cause trouble for the world. After verification of a security issue, you can bet that it becomes the top priority for developers to fix, and quickly you will see an announcement of an upgrade. When that occurs, you should upgrade immediately, even if you don’t use the particular element that is the cause of the security issue. A hole is a hole. Why leave it uncovered?
Here is an example of the Apache changelog documenting a change that occurred between version 2.0.61 and 2.0.63 (version 2.0.62 was not released to the public) that indicates a need to upgrade:
SECURITY: CVE-2007-6388 (cve.mitre.org)
mod_status: Ensure refresh parameter is numeric to prevent a possible XSS
attack caused by redirecting to other URLs.
A good rule of thumb is that if the word security appears anywhere in the changelog, you should upgrade. In the PHP 5 changelog, at http://www.php.net/ChangeLog-5.php, security-related fixes are grouped together and tend to be at the top of the list because of their importance.
However, if the release is just a maintenance release, meaning that it contains bug fixes and general enhancements that occur through normal development, you probably do not need to drop everything and upgrade your software. Here are some examples of maintenance items from the Apache and PHP changelogs, respectively:
mpm_winnt: Eliminate wait_for_many_objects. Allows the clean shutdown of the server when the MaxClients is higher then 257, in a more responsive manner.
Fixed bug #43137 (rmdir() and rename() do not clear statcache).
If nothing in the list of changes is relevant to you, your work, or your environment, you could probably put off the upgrade until scheduled downtime or a rainy day. For example, if all the bugs fixed in a maintenance release of PHP have to do with the Windows platform and you run PHP on Linux, you can put the task aside, worry-free.
Even if you do not immediately upgrade your software, it is a good idea to stay at least within a few revisions of the current production version of the software. Anything past that and it becomes more likely that new features would be added or bugs fixed that are indeed relevant to your work or your environment.
Whether you use UNIX/Linux or Windows, upgrading versions of MySQL is simple: Install the new version as if the other version does not exist.
Before upgrading to a new version of MySQL, always back up your existing databases.
Updates to MySQL are quite simple within the same base version; 5.4 is a base version, 5.5 is a base version, and so on. This means that upgrading any revision in the 5.5.x family is as simple as installing the new software on top of the old software. With the Windows Installer, this is all invisible to you but is exactly what occurs. UNIX/Linux users who install from the binary distribution simply relink the mysql symbolic directory to the new, unpacked distribution, as part of the installation process.
If you run into problems during the upgrade process, refer to the troubleshooting tips at http://dev.mysql.com/doc/refman/5.5/en/upgrading.html. However, upgrading minor versions of MySQL has always been a painless experience for me, on multiple platforms.
If you change character sets when upgrading, you must run the following command to adjust the collation of your existing data:
# myisamchk -r -q --set-collation=new_collation_name
As with MySQL, upgrading or rebuilding Apache follows the same process as installing the software in the first place. Windows users have the benefit of an installer application that automatically detects the previous version, removes core components, and installs new ones. The Windows Installer will, however, retain existing configuration files. You are responsible for upgrading any other version-specific modules that may be tied to specific versions of Apache.
For UNIX/Linux users, the process also follows the same path as the original installation. When you unpack your new distribution, it creates a directory named with the new version number. For example, if your previous version was 2.2.17 and you are upgrading to 2.4.1, your directories will be named httpd-2.2.17 and httpd-2.4.1, respectively.
The actual installation directory for Apache is determined by you, when you run the configure script, as in this example:
# ./configure --prefix=/usr/local/apache2
After running the configure script to build the new version of Apache, just go through the make and make install process as you did when installing Apache in the first place.
Now, should you want to install your new version of Apache directly over your old version, you can—even with the old httpd binary still running. Just be sure to back up your configuration files in case something goes awry. However, if you are more comfortable installing your new version in a different directory, that’s fine, too; you just have to move all your web-related files (that is, everything in the document root) to the new directory and make all appropriate edits to your fresh, new httpd.conf file. Whichever method you choose is up to you. (One method just requires more file movement and reconfiguration than the other.)
After upgrading Apache on UNIX/Linux, you should also rebuild your PHP module. Windows users do not have a module to rebuild but should ensure that the appropriate PHP-related changes are still present in the httpd.conf file related to loading the module residing in the PHP directory tree.
Modifying Apache Without Upgrading
Suppose that you need to add or remove functionality from Apache but are not upgrading to a new minor version. An example is to add a new module or to upgrade the version of OpenSSL used on your system.
In this case, UNIX/Linux users should go to the existing source directory (such as httpd-2.2.17, using the earlier example) and type make clean at the prompt. This will, essentially, reset the makefiles so that you can rebuild Apache without relying on previous, cached values. After the make clean command, run the configure script with your new parameters, and go through the make and make install process again. You do not need to rebuild the PHP module in this situation.
Windows users would activate the prebuilt modules by uncommenting the appropriate lines in httpd.conf or by adding the lines if they do not already exist.
Given that UNIX/Linux users can add so much functionality to PHP through various build options, it is likely that you will upgrade or modify PHP more often than Apache or MySQL. Regardless of whether you are upgrading to a new revision or minor version or simply adding new functionality (or removing some you no longer need), the process for modifying an existing version is exactly the same as installing it in the first place: configure, make, make install. The make install step places the PHP module in the appropriate place in the Apache directory tree. When your new module is in place, restart Apache—the new version of PHP should be in use.
When you upgrade PHP to a new version, you will have a completely distinct directory tree when you extract the distribution archive, based on the new version number. Perform the configure, make, make install steps within this new directory structure, and a new PHP module will be built, independent of the other.
Windows users have a different set of tasks to perform: Adding new functionality to an existing module requires only that you activate the module by uncommenting its entry in php.ini and then restart Apache. Upgrading to a new minor version requires you to download a new distribution file. The contents of this file extract into a directory named for the version it represents. You must then follow the steps required for installation, regarding the configuration of php.ini, because each version produces a different file. Finally, change any PHP-related pathnames in the Apachehttpd.conf file and restart the server. The new version of PHP should be in use.
Using PECL and PEAR to Extend PHP
You can obtain a wealth of user-created extensions and applications from PECL (the PHP Extension Community Library, at http://pecl.php.net/), and PEAR (the PHP Extension and Application Repository, at http://pear.php.net/). These sites are governed by rules and style guides, so everything you download from these sites is of high quality.
If you are looking for additional extensions for your PHP installation, look to PECL. If you are looking for a library of open source code to integrate in your application, look to PEAR.
This short chapter provided some guidelines for keeping your installations of MySQL, Apache, and PHP current. You learned where to look for updates and how to weigh the importance of upgrading to a new version. In addition, you learned the step-by-step processes for upgrading or modifying MySQL, Apache, and PHP.
The workshop is designed to help you review what you’ve learned, and begin putting your knowledge into practice.
1. How would you refer to software in which the major version is 3, the minor version is 4, and the revision is 14?
2. What is considered the primary reason for upgrading to a new minor version of any software?
3. What command cleans up previous makefiles and cached settings?
1. The full version number would be 3.4.14.
2. Security issues that have been found and fixed by the developers.
3. The make clean command.
By the time you read this chapter, it is very likely that one or more of PHP, MySQL, and Apache will have a different version number than the ones either included on the CD or that you downloaded and installed at the beginning of the book. So, if you have the permissions to upgrade (that is, if you are not using a virtual hosting environment), just pick one (or more) of the technologies and go through the upgrade process.