Posts Tagged ‘Apache’

IUS Community RPMs for Red Hats RHEL

Sunday, May 16th, 2010

I was criticizing that software in RHEL is too outdated for web servers quite soon after release, see my blog post While this is true for a system fully supported by Red Hat, I learned an alternative from a comment on the post. This alternative is the so called IUS community repository.

About the IUS Community Project
The project was launched in September 2009. In spite of being a young project, it has a history. At Rackspace, a large hosting company which is operating thousands of production (web) servers, it was an internal project since 2006. They decided to build up a community around it, like Fedora is for RHEL, Quote: “IUS is The Fedora of Rackspace RPMS”

Like for other community repositories out there, you cannot expect a “official” support neither from Red Hat nor from IUS or Rackspace. Of course there are the usual support sources for communities such as forums, IRC, bugtracker etc.

The difference to other repositories
While most community repositories such as EPEL, rpmforge etc. are focused on providing missing software, IUS focuses on providing upgrades for web server related software which is included in RHEL. This includes PHP, Python, MySQL and others.

Package conflicts with the stock distribution
One may think replace stock software with newer version is tricky and create conflicts. There is one way to find out: Lets give it a try…

The test
The server is a basic install of the yesterday released Centos 5.5. The following installation turns this machine in a lightweight LAMP server:

yum install httpd php-mysql php php-cli php-common php-pgsql php-dba php-pdo php-gd mysql-server perl-DBD-MySQL.

Now we have the situation like it exists in many companies: An outdated webserver. Now we want to upgrade PHP to 5.3.x. Lets see what happens.

[root@centos5 ~]# rpm -i
warning: /var/tmp/rpm-xfer.o6JH6k: Header V3 DSA signature: NOKEY, key ID 9cd4953f
[root@centos5 ~]# rpm -i
warning: /var/tmp/rpm-xfer.MRnuo8: Header V3 DSA signature: NOKEY, key ID 9cd4953f
package epel-release-5-3.noarch (which is newer than epel-release-1-1.ius.el5.noarch) is already installed
[root@centos5 ~]#

Hmm… no GPG key…
The second output is confusing me. Is the package just a clone of epel-release-5-3.noarch? Lets go forward to see if it is working.

“yum clean-all && yum check-update” did not show any pending updates, so far so good. Now lets try to upgrade php.

root@centos5 ~]# yum install php53
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons:
* base:
* epel:
* extras:
* ius:
* updates:
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php53.x86_64 0:5.3.2-3.ius.el5 set to be updated
--> Processing Dependency: php53-common = 5.3.2-3.ius.el5 for package: php53
--> Processing Dependency: php53-cli = 5.3.2-3.ius.el5 for package: php53
--> Processing Dependency: php53-pear >= 1:1.8 for package: php53

[omitted output]

--> Processing Conflict: php53 conflicts php < 5.3
--> Finished Dependency Resolution
php53-5.3.2-3.ius.el5.x86_64 from ius has depsolving problems
--> php53 conflicts with php
Error: php53 conflicts with php
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
The program package-cleanup is found in the yum-utils package.

Correct behaviour, since it is a replacement package. After removing php (and only php) yum was complaining about more conflicts. After removing all php related packages installed to prepare for the test, needed to be removed. So the dependencies has been proper solved. Also the installation of related stock distribution packages such as “php-pgsql” has been successfully prevented.

The IUS community repositories are working as expected. With such a basic test I cannot promise if there are not hidden conflicts with packages between stock RHEL/CentOS packages and those from IUS. The experience on the long term will bring more clarity. I think is is sane to do some real-life tests with servers that are in an early project phase.

Further readings:

Have fun!

An example why open source software is cool

Saturday, May 15th, 2010

Recently I have set up an Apache Tomcat. As a replacement for the Tomcat manager I deployed Psi-Probe for easy deployment and access to statistics.

Afterwards I installed the production software which needs to add a JVM parameter to have the proper date and time format used in Switzerland. This had a unwanted side-effect to Psi-Probe. The Interface switched to German, no way to switch the language back to English. Since my mother tongue is German, no big deal so far. Really? No! I had really problems to understand what navigation items etc.  are meaning. The German translation was that bad, it actually crippled the application.

I had the choice to either life with it, or change it and contribute it to the project. I made the later. It was about one hour of work. Hours after submitting, the changed translation file it was in SVN. The next version now comes with a much improved German translation.

This is how open source software works. If someone is not happy with the product, simply change the annoying things and submit it upstream. By the way: Psi-Probe itself is a fork of Lambda-Probe which was not maintained anymore from its origin project owner.

Try to do that with closed source software…

Have fun!

Apache HTTP server and its further development

Monday, May 3rd, 2010

The Apache httpd is one of the most stable software pieces which is still in use. The latest huge step forward was with the release of 2.0. Quo vadis Apache httpd? The most current release is 2.2.15. During the 2.2.x release cycle, there have basically been only bug-fix releases (Okay, response header rewrite starting on 2.2.9  is a nice feature). This brings me to the question: What is going on with 2.4?

The answer is quite simple: As you can read on, not much. Why is the Apache httpd developing so slow? From my point of view the answer is quite simple: Apache httpd is finished. It is stable, reliable and has (almost) all features people wish. @Apache httpd developers: Great job! Thanks a lot!

Additionally there are tons of external modules to enhance the capabilities of this really great piece of software.

Honestly I can not publish my wish-list for the Apache httpd because there are no open wishes for me. Can someone have such a wish list? Please let us know and write a comment.

Have fun…

RHEL6 as a web server

Sunday, May 2nd, 2010

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.


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!

302 Redirects behind SSL-terminating proxies

Thursday, October 29th, 2009


You have a web site all with SSL. There is a reverse proxy or load balancer that acts as SSL termination point. Behind that reverse proxy you have an Apache web server running plain http.

Your application uses 302 redirects to announce new URLs or whatever the reason is for doing so. Since the web server does not know that https URLs should be announced, the response header is wrong and looks like following:


The browser interprets that location header and send a request to this non-SSL URL instead of https:///

If your reverse proxy does not know how to handle this, a connection will time-out. How to circumvent this if you have access to the web server but not to the reverse proxy or load balancer? What to do if your load balancer (such as Blue Coat devices) are closed down appliances that are not able to rewrite response headers?

Search engines do obviously not know the answer or I simply did not asked the right question.


Since Apache version 2.2.4 mod_headers is able to rewrite response headers. Just add the following to your httpd.conf

Header edit Location ^http://(.*)$ https://$1

This configuration statement will solve your problem. Redirects triggered by your back end web servers will be re-rewritten to comply with your SSL terminating reverse proxy/load balancer.

Further reading: mod_headers

Have fun….