This week, Red Hat has rolled out RHEL 5.3,. We’ve been busy pushing it out to our servers as we like to keep them updated. Along with the 5.3 release, Mark Cox posted an interesting article on the risk profile of 5.2. He’s examined the number of patches that have been submitted since the 5.2 release in May of 2008. For a default install, which many of our clients use, there were 45 advisories to address 127 vulnerabilities. This is 127 patches in 8 months. Seven advisories were rated critical, 21 were important, and the remaining 17 were moderate and low.
Stock is Best
Stats are great but there is a more important chart in this article which underscores why we discourage our clients from using software from third party sources. As you can see in the chart to the right. What you see here is the number of errata issued per month for each successive release. As Red Hat Releases mature, they typically require fewer updates. Fewer updates means fewer potential service impacts due to new patches. We also find that systems tend to become more secure and stable as the release progresses.
When you use third-party or non-standard software packages (RPMS), you introduce a new management task, possibly increase your security risk profile, and increase the complexity of your operations. Do to these reasons, we often discourage using third party or alternate RPMS when possible.
PHP Example
We often get requests to have PHP upgraded to a non-standard version. For example, running PHP 5 on RHEL 4. While this is doable, doing so diminishes the benefits you see in the chart. When you introduce a non-standard software package, you are eliminating the benefits that Red Hat provides. Timely, tested patches are critical for operational stability and service continuity.
Even for a subtle change, you now can no longer deploy Red Hat patches, but must check your 3rd party source for the updates. What if they do not build the package in a timely fashion? You then have to build it yourself (or get us to build it). This of course takes time which of course means increased costs. By sticking with the stock PHP packages, you save yourself these headaches.
When to Customize?
I often find that demanding the latest version is simply that — a demand for the latest version. However, there are situations in which running a non-standard version may be required. For example, if you have a program that absolutely will not run on your current versions, you may find it better to run a non standard software package than to upgrade or migrate your server. There may be some functions provided by a third party package that is not included in Red Hat directly. These are both good reasons for using alternate software.
What to Use?
When you must use alternate software, I prefer to use sources that you can trust. Top on my list are CentOS Plus releases, EPEL, and Dag Wieers archive. I’ve used these resources many times. They have good support or user community behind them to keep the updates coming.
TCO, Stability, and Security
By using the stock packages, we can easily keep systems updated. As a result, you have better stability, increased security and lower total cost of operations. So when we strongly recommend you not switch to that latest version of package X, we do have broader goals in mind. While we are not fond of building custom RPMS, we can do so, but in most cases the alternate versions can be avoided.