New software versions
Today I’m writing about the changes and benefits of RHEL6 as a web server compared to RHEL5. Red Hat is well known for its stable API and ABI over the life-cycle of a major release. For some usage types this is a major problem. Sticking to old version of PHP, MySQL, Tomcat you-name-it-piece-of-software is problematic since web applications are rapidly changing its requirements.
- Instead of PHP 5.1.6, RHEL6 ships almost up-to-date PHP 5.3.1. Which is good, since web applications such as TYPO3 require PHP 5.3 to be able to install security bug fixes.
- The Apache httpd comes in Version 2.2.14 instead of 2.2.3. Since Apache is not very actively developed further, it does not matter anyway.
- MySQL is shipped with an almost-up-to-date version 5.1.42 vs. 5.0.77. No big deal.
- Tomcat is being installed with version 6.0.20 instead of the very old 5.5 in RHEL5. This brings quite some benefits for Java web developers.
- Nothing has changed since RHEL5.5 so far for PostgreSQL. Since RHEL5.5 Red Hat ships version 8.4 in addition to 8.1.
- Python got upgraded from 2.3 to 2.6 which probably allows to run more Python based web applications.
- Unfortunately still no appearance of GraphicsMagick as a replacement for ImageMagick.
- New: Ships with APC (Alternative PHP Cache). This is useful for LAMP servers with loads of traffic and helps to get response time below critical values.
Unlike other distributions, Red Hat’s default DocumentRoot is still in /var/www instead of /srv/www. From my point of view the /var should be used for libraries and similar stuff, but not for application data. This ends up in creating symlinks like it was before.
From the “I-dont-like-bloated-systems” Departement
Looks like Red Hat made a huge progress in making its system less bloated. In Versions up to RHEL5 you can experience strange package dependencies.
- PHP and friends: While on RHEL5 a “yum install php” automatically selects PostgreSQL-libs and gmp to install, nothing like this happens on RHEL6.
- Tomcats dependencies went down from 48 packages to only 15.
Conclusion
At the end of the day, Red Hat made a good job to enable RHEL as a web server again. The fundamental problem is still the same: In two years RHEL6 will be completely outdated and not useful for modern web application, like it is today with RHEL5. Of course you can compile the stuff by yourself, but then you’ll get a maintenance problem.
Red Hat should think about something similar like Debian’s “volatile” repository. It provides upgraded software which would otherwise be useless in a two years or older versions. I’m looking forward for a “Red Hat Volatile” Channel on our satellites.
Feedback is welcome…
Have fun!
I mainly use HPC, so I really interested in Cluster and GFS2. RHEL 5 has a lot of improvement in Cluster suite over RHEL4, however, it’s still difficult to manage and pin point the problem within multiple nodes. I hope that RHEL 6 provide better tools for managing cluster and gfs.
John,
You may have a look at http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Beta_Release_Notes/clustering.html and http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Cluster_Suite_Overview/
I did not got the time (yet) to have a closer look at the changes.
Within the Fedora Project, EPEL is a add-on repository for Fedora and we intend to provide parallel installable newer versions and many many add-on packages (over 4000 already for EL 5). There is also the IUS repo which is complimentary to EPEL but conflicts with the base EL packages. EPEL is not commercially supported by Red Hat but several Red Hat engineers contribute to the repo
https://fedoraproject.org/wiki/EPEL
http://iuscommunity.org/
Dear Rahul,
I know EPEL and I love it 🙂 Its makes my daily work much more comfortable, thanks a lot.
I was not aware of IUS, thanks for the hint.
The problem persists, RH should provide newer version by them self, like they did it with PostgreSQL in RHEL5.5. The reason for that is enterprises wishes to have a “fully supported” OS.
Thanks,
Luc