Apache to mongrel proxy permission denied on CentOS 5.1

Here's a brief tip for those of you about to set up Ruby on Rails, mongrel and Apache web server on CentOS 5.1: don't forget that you may have SELinux enforcement policies in place by default that prevent proxy balancers to connect correctly.

Now, you probably have proxy directives like the following in your httpd.conf file:

<Proxy balancer://mongrel_cluster>
  BalancerMember http://localhost:3000
  BalancerMember http://localhost:3001
  BalancerMember http://localhost:3002
</Proxy>

Firing up your mongrels and kicking up httpd will result in errors like this in your Apache errors logs:

[Thu Apr 24 23:24:20 2008] [error] (13)Permission denied: proxy: HTTP: attempt to connect to localhost:3000 (myserver) failed
[Thu Apr 24 23:24:20 2008] [error] ap_proxy_connect_backend disabling worker for (myserver)
[Thu Apr 24 23:24:21 2008] [error] proxy: BALANCER: (balancer://mongrel_cluster). All workers are in error state
[Thu Apr 24 23:24:21 2008] [error] proxy: BALANCER: (balancer://mongrel_cluster). All workers are in error state
[Thu Apr 24 23:24:21 2008] [error] proxy: BALANCER: (balancer://mongrel_cluster). All workers are in error state

Hm... alright, but what does /var/log/messages have to say?

Apr 24 23:24:19 myserver setroubleshoot:      SELinux is preventing the /usr/sbin/httpd from using potentially mislabeled files / (unlabeled_t).      For complete SELinux messages. run sealert -l 7e096a76-b66f-48f9-a30e-d736dbb6007d

Actually running that sealert command won't tell you any more beside the fact that SELinux is denying httpd access to potentially mislabeled files. Whatever that means. But perusing section 44.2.6. Enabling or Disabling Enforcement of the CentOS 5.1 deployment guide, there is enough there to resolve this obstruction.

Executing the sestatus command lets us see what SELinux is doing to protect our server.

[root@myserver]# sestatus -b | grep httpd
...
httpd_can_network_connect              off
...

Aha! This boolean property looks like it could be one that is denying the proxy connection from httpd to mongrel. So, let's enable this, shall we? The command to do this is setsebool. Reading the friendly man pages before running this command, we learn that setsebool will only set the current, running state of the boolean in question, and that if we desire to have this setting survive reboot, then we need to use the -P flag. Let us do exactly that:

[root@myserver]# setsebool -P httpd_can_network_connect=1

Now when you restart your mongrels and httpd, you will see that the proxy connections are good to go. And our configurations will live on, even after reboot. Sweet!

PostgreSQL 8.3.1 RPM's on CentOS 5.1

CentOS 5.1./RHEL5 comes with PostgreSQL 8.1.9, but if you are like me and want to enjoy the latest and greatest from the world's most advanced open source database, then you might want to try installing the PostgreSQL 8.3.1 RPM packages.

However, you will find that the postgresql-libs package has quite a few dependencies, not the least among them is apr-util, which is used by httpd. Deciding to go against the grain (and most common sense with respect to the entire premise of CentOS), I recently made a haphazard installation attempt whereby I blindly removed the postgresql-libs package with the rpm --nodeps option. My Apache web server refused to start, complaining about conflicts related to libpq.so.4 after I thought I successfully installed PostgreSQL 8.3.1. Luckily, this was all on VirtualBox, so recovery was not a problem.

Let me save you some time and headaches by outlining briefly the steps you can take to resolve this dependency issue by replacing the files upon which these dependencies lie by installing the compat-postgresql-libs-4, using the --replacefiles option.

First, go ahead and fetch the PostgreSQL RPMs for 8.3.1. And make sure you grab the aforementioned compat-postgresql-libs-4 RPM, too. I found all of the RPMs needed here at this archived repository.

Next, go ahead and start removing the 8.1.9 PostgreSQL packages with the rpm utility, saving the postgresql-libs package for last.

# rpm -e postgresql-contrib
# rpm -e postgresql-server
# rpm -e postgresql

Now when you attempt to remove the postgresql-libs package, you may see this:

# rpm -e postgresql-libs
error: Failed dependencies:
    libpq.so.4 is needed by (installed) apr-util-...
    libpq.so.4 is needed by (installed) exim-n...
    libpq.so.4 is needed by (installed) mod_auth_pgsql-...
    libpq.so.4 is needed by (installed) dovecot-...
    libpq.so.4 is needed by (installed) perl-DBD-Pg-...
　　...

The key here is libpq.so.4, which refuses to go quietly into the night when attempting to install PostgreSQL 8.3.1. So what are we to do? Well, let's take a closer look at what happens when we try to install the compat-postgresql-libs-4 RPM.

# rpm -i compat-postgresql-libs-4-1PGDG.rhel5.i686.rpm
     file /usr/lib/libpq.so.4 from install of compat-postgresql-libs-4-1PGDG.rhel5 conflicts with file from package postgresql-libs-8.1.9-1.el5
     file /usr/lib/libpq.so.4.1 from install of compat-postgresql-libs-4-1PGDG.rhel5 conflicts with file from package postgresql-libs-8.1.9-1.el5

Aha! Here we've found where the conflict lies. Let's work around this by replacing the existing libpq.so.4 from the original 8.1.9 with that from compat-postgresql-libs-4-1PGDG.rhel5.i686.rpm.

# rpm -iv --replacefiles compat-postgresql-libs-4-1PGDG.rhel5.i686.rpm

We are now home free! Continue by uninstalling the old postgresql-lib package, and you can then start the 8.3.1 package install. There should be no more trouble with dependencies for libpq.so.4, since it still exists but has been swapped out with that of compat-postgresql-libs-4-1PGDG.rhel5.i686.rpm. Good to go.