Using Apache for proxying connections to Crucible

Atlassian’s web applications are great tools for software development and they are relatively easy to setup because they come with Jetty servlet container and HQSQL database. You only have to install Java. Some of the applications can be also run like any normal deployable WAR-packaged web application for example with Apache Tomcat which gives you more control and administration options. But unfortunately code review tool Crucible isn’t one of those applications and maybe will never be.

Proxying connections to Crucible

By default Crucible runs in port 8060 which isn’t nicely looking for users. It’s way better to use ports 80 or 443 which are normal HTTP and HTTPS ports and are omitted from browser’s address bar. Of course you can configure that in the Administration screens, or by editing Crucible’s config.xml and restarting Crucible but if you run Crucible as a non root or also have other software running on the same server that isn’t an option.

One solution is to use Apache HTTP server to proxy connections from port 443 to Crucible’s listening port. I did it for Crucible and FishEye on CentOS x86_64 but things are mostly the same also on other Linuxes. I also disabled the HTTP port and used just the SSL enabled HTTPS with self generated certificates.

First we setup Apache for proxying connections to Crucible and then we generate some SSL certificates for HTTPS. If you haven’t Apache installed you can do it with yum like: yum install httpd.x86_64 mod_ssl openssl

1. Set HTTPS proxying in /etc/httpd/conf.d/ssl.conf

...

SSLProxyEngine on
ProxyRequests Off
ProxyPreserveHost On
ProxyPassReverse /crucible ajp://127.0.0.1:8060/crucible
proxyPass /crucible ajp://127.0.0.1:8060/crucible

RewriteEngine On
...

2. Generating SSL Certificate for Apache

# openssl genrsa -out localhost.key 1024
# openssl req -new -key localhost.key -out localhost.csr
# openssl x509 -req -days 365 -in localhost.csr -signkey localhost.key -out localhost.crt
# mv localhost.csr localhost.key /etc/pki/tls/private/
# mv localhost.crt /etc/pki/tls/certs/

3. Start httpd

# service httpd start

Configuring Crucible

4. Configure Crucible (http://hostname:8060/admin)

Edit Web Settings:
-----------------
Web context: crucible
Http Bind: (none)
Ajp13 Bind Address: ajp://127.0.0.1:8060/crucible

And you’re ready.

Using PHP-FPM with Apache 2 on CentOS

Running Apache 2 and PHP is simple with mod_php but there are more efficient alternatives like using PHP-FPM (FastCGI Process Manager) which is an alternative PHP FastCGI implementation. With it the PHP process runs standalone without the need for a web server and listens for incoming requests on either a TCP or a Unix socket. Web servers can connect the PHP process and send requests using the FastCGI protocol. It solves mod_php’s problem of spinning up and destroying PHP instances with every request and thus is more memory efficient and provides better performance.

These instructions are for CentOS 6.4 but the process should however work similarly with other Linux distributions.

Setting up the PHP-FPM

Install the FPM-CGI binary for PHP and add it to start after server reboot:

# yum install php-fpm
# chkconfig --levels 235 php-fpm on

Configure the PHP-FPM pool in /etc/php-fpm.d/www.conf to use sockets and enable some status information for e.g. Munit:

;listen = 127.0.0.1:9000
listen = /tmp/php5-fpm.sock
pm.status_path = /status
ping.path = /ping

Start the service with:

service php-fpm start

Setting up Apache and mod_fastcgi

Apache can be configured to run FastCGI with two modules: mod_fastcgi and mod_fcgid. The difference is explained at Debian bug report #504132: “mod_fcgid passes just one request to the FCGI server at a time while mod_fastcgi passes several requests at once, the latter is usually better for PHP, as PHP can manage several request using several threads and opcode caches like APC usually work only with threads and not with processes. This means that using mod_fcgid you end up having many PHP processes which all have their very own opcode cache.”

In short: mod_fastcgi is better.

Install mod_fastcgi

So we need to get mod_fastcgi which isn’t at the time found from CentOS default or EPEL repos but from RPMForge or by building it from sources.

Getting mod_fastcgi from RPMForge

Install the RPMForge repo:

# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
# rpm -ivh rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

Add some priorities which repo to use:

# yum install yum-priorities
 
# vi /etc/yum.repos.d/epel.repo 
... add the line priority=10 to the [epel] section

Install mod_fastcgi

# yum install mod_fastcgi

Or building mod_fastcgi from sources

You can build the mod_fastcgi from sources. Make sure required packages are installed (httpd-devel and apr-devel required to compile mod_fastcgi):

# yum install libtool httpd-devel apr-devel apr

Get the latest mod_fastcgi source code:

# cd /opt
# wget http://www.fastcgi.com/dist/mod_fastcgi-current.tar.gz

Untar tar ball:

# tar -zxvf mod_fastcgi-current.tar.gz
# cd mod_fastcgi-2.4.6/

As we are using Apache 2, we make a copy of Makefile.AP2: cp Makefile.AP2 Makefile

Compile and install mod_fastcgi for 64 bit system:

# make top_dir=/usr/lib64/httpd
# make install top_dir=/usr/lib64/httpd

Configure mod_fastcgi

If you have php enabled disable it

# mv /etc/httpd/conf.d/{php.conf,php.conf.disable}

Set up a (non-existent) directory that Apache can route the requests through. That directory must be available to Apache and it might be /usr/lib/cgi-bin/ so the routed file is then e.g. /usr/lib/cgi-bin/php5-fcgi.

# mkdir /usr/lib/cgi-bin/

Configure mod_fastcgi settings in /etc/httpd/conf.d/mod_fastcgi.conf to be:

LoadModule fastcgi_module modules/mod_fastcgi.so
 
<IfModule mod_fastcgi.c>
	DirectoryIndex index.php index.html index.shtml index.cgi
	AddHandler php5-fcgi .php
	Action php5-fcgi /php5-fcgi
	Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
	FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /tmp/php5-fpm.sock -pass-header Authorization
 
	# For monitoring status with e.g. Munin
	<LocationMatch "/(ping|status)">
		SetHandler php5-fcgi-virt
		Action php5-fcgi-virt /php5-fcgi virtual
	</LocationMatch>
</IfModule>

We add handler and action which sends all requests of PHP to the virtual URL created above, which is in turn then sent to the external FastCGI server. We also add configuration to have some status information about our PHP-FPM.

Start Apache:

# service httpd start

PHP should now work.

WordPress mod_rewrite rules taking over mod_status and mod_info

After moving Rule of Tech to a new server and setting up monitoring I noticed that server-status and server-info Apache modules weren’t working as expected. As usual a little bit of Googling solved this problem.

The problem was that the .htaccess rules in WordPress were taking over non-existing server-info and server-status urls given in Apache’s config and were returning a page not found error. The rewrite rules by WordPress were setup to handle all the permalinks on the site and for any non-existing file send it to index.php. It really wasn’t a WordPress problem and should happen with any application that uses the same type of catch-all rewrite rules to handle all the urls inside the application.

The solution was to specifically add a rewrite rule to not have the server-status and server-info urls processed by adding a rule like: RewriteCond %{REQUEST_URI} !=/server-status. The other way is to stop the rewriting process when the urls are found by adding a rule like: RewriteRule ^(server-info|server-status) - [L].

The WordPress rewrite rules should look like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# server info and status
RewriteRule ^(server-info|server-status) - [L]
# RewriteCond %{REQUEST_URI} !=/server-status
# /server info and status
RewriteCond %{REQUEST_FILENAME} -f 
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . index.php [L]
</IfModule>
# END WordPress