Downside to Enterprise Linux
(Note: For the purpose of this post CentOS is equivalent to RHEL)
It has been about 2 and 1/2 years since I built a dedicated server and chose CentOS instead of Fedora. Since I installed CentOS 5.1 I have used the upgrade process 4 times with no problems bringing me to version 5.5 with practically no re-installation, re-configuration or troubleshooting upgrade issues. This is the goal of enterprise linux. A long term stable solution with no major changes to preserve compatibility with every piece of software that was provided since it was released (in this case April 2007). In the time I’ve been on CentOS I’ve upgrade/replaced Fedora at least 5 times on other machines. Each time learning the changes to software, languages, security and many other components.
I’m very pleased with CentOS knowing that after the next yum update all my software will keep working. And everything is 100% secure.
However the exact reason enterprise linux is so great is also the exact reason why it can be a major pain. Once a main component is locked down, Red Hat will not provide updates unless needed for security or stability.
An objective for my server was for web development. The state of web as defined in 2007 when RHEL was created is coming close to obsolete. CentOS 5 includes PHP version 5.1.6. However PHP 5.2, which was released before RHEL 5, has become the default standard requirements for many PHP applications. I was updating some code to utilize JSON when I realized I would have to deviate from standard updates to install PHP 5.2 on CentOS. (This wasn’t too bad)
Another objective was a file server and backups. I’ve been playing with DropBox (*) as means of an off-site backup solution. What makes it great is it’s support for Linux! Even text-based linux which is what my server is. However the first requirement is Python 2.5. CentOS uses 2.4, and you can’t do a major update of Python in a CentOS/Fedora install without breaking many things since this is a critical component. You can do a parellel install for Python 2.5 but this is a bit annoying to maintain as you have 2 versions of python installed. (I have yet to get Dropbox working well on my server)
I also have been writing C++ software using boost. I recently realized the asio library was standard in boost 1.37 and later. I was locked to 1.33 in CentOS 5. No big deal since, the boost package was not critical for me in CentOS and it could be easily replaced. So I decided to recompile a newer Fedora boost src.rpm. However I would see errors like this:
error: unpacking of archive failed on file /home/mirandam/rpmbuild/SOURCES/boost-1.41.0-iostreams-zlib.patch;4c7880e5: cpio: MD5 sum mismatch
The above error is simply because Fedora 12 changed the RPM compression algorithm used and rendered older versions of RPM incompatible with newer packages. I don’t dare meddle with RPM as it is a core component, so I ended up compiling an older Fedora 11 version of boost 1.37 src.rpm which did the job.
Overall I’m still happy with my setup, but slowly I’m spending a great deal of time patching different pieces as my needs have slowly evolved. Interestingly Red Hat recently announced extended support lasting up to 10 years. That seems way too long considering the state of software (although everyone still uses Windows XP - now 9 years old).
I’m getting a little antsy running 3 year old software. The good news is that RHEL 6 is in beta, which means that soon after release the totally free CentOS 6 will follow as well. Which I’m eagerly waiting for, because all my issues will be addressed … at least for the time being.
(*) Affiliate link - I highly recommend Dropbox.
Posted in: CentOS, Development, Fedora, Linux, Miscellaneous, Opinion, Red Hat, Server,
1 Comments:
Rahul Sundaram on November 20, 2010 - 02:14 PM
“Interestingly Red Hat recently announced extended support lasting up to 10 years. That seems way too long considering the state of software”
You might consider it way too long however there are paying customers willing to pay more in special cases to extend the lifecycle even more. Their hardware refresh cycle might be even 15 years and they don’t want to change their OS in between. It costs them several millions of dollars to do any change in their enterprises. This is the reality of the many large customers.