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.

Running FishEye & Crucible as a service in Linux

Atlassian’s tools for supporting software development are great but they aren’t really admin friendly to start with. For example FishEye & Crucible doesn’t ship with scripts to start it at system boot time but with the help of Atlassian’s Wiki, sysadmin tasks and scripts you can run it as a normal service. First we create a dedicated user for crucible and second we add a new service for it. I have done this on CentOS 5.7 x86_64.

Setting up the service account

As the root user, create a separate “FishEye & Crucible” service account at root shell:

# useradd -c "FishEye & Crucible service account" -d /home/crucible -m crucible

To make it easier for this to work also after FishEye & Crucible upgrades we create a symbolic link to the latest version (modify “/opt/fecru” to match your deployment).

# ln -s /opt/fecru/fecru-2.7.15 /opt/fecru/latest

Then, ensure that this user is the filesystem owner of the FishEye & Crucible instance (modify “/opt/fecru” to match your deployment).

# chown -R crucible:crucible /opt/fecru

Running Crucible as a crucible user

Save the following script to /etc/init.d/crucible. Be sure to edit the FISHEYE_HOME value to the location where your FishEye/Crucible instance resides:

#!/bin/bash
# RUN_AS: The user to run fisheye & crucible as. Its recommended that you create a separate user account for security reasons
RUN_AS=crucible
 
# FISHEYE_HOME: The path to the FishEye & Crucible installation. Its recommended to create a symbolic link to the latest version so the process will still work after upgrades.
FISHEYE_HOME="/opt/fecru/latest"
# FISHEYE_INST: The path where the data itself will be stored.
export FISHEYE_INST="/opt/fecru/fecru-data"

fisheyectl() {
        if [ "x$USER" != "x$RUN_AS" ]; then
                # If running without FISHEYE_INST
                # su - "$RUN_AS" -c "$FISHEYE_HOME/bin/fisheyectl.sh $1"
                su - "$RUN_AS" -c "FISHEYE_INST=$FISHEYE_INST $FISHEYE_HOME/bin/fisheyectl.sh $1"
        else
                "$FISHEYE_HOME/bin/fisheyectl.sh $1"
        fi
} 

case "$1" in
        start)
                fisheyectl start
                ;;
        stop)
                fisheyectl stop
                ;;
        restart)
                fisheyectl stop
                sleep 10
                fisheyectl start
                ;;
        *)
                echo "Usage: $0 {start|stop|restart}"
esac
 
exit 0

After saving the script, modify it’s permissions so that it can be executed:

# chmod 755 /etc/init.d/crucible

Running Crucible as a service

Now that we have an init script we can add it as a service and be able to configure the system to run the script on startup (more precisely, ensure that Crucible runs in runlevels 3, 4 and 5):

chkconfig --add crucible
chkconfig crucible on

Verify that the script has been installed correctly:

# chkconfig --list crucible

After this has been done you can manually start or stop the service by using these commands:

service crucible stop
service crucible start

And you’re done.

Keeping up with the time in Xen

A simple tip for keeping up with the time in Xen when your domU isn’t syncing the clock frequently enough and your clock is whatever. Of course you can sync your clock with ntpdate but first you need to set the domain (domU) to run its wallclock independently from Xen.

Simply say in the command line of domU:
echo 1 > /proc/sys/xen/independent_wallclock

Or if you have noclobber on:
echo 1 >! /proc/sys/xen/independent_wallclock

To reenable tracking of Xen wallclock:
echo 0 > /proc/sys/xen/independent_wallclock

And to keep the setting between reboots, just add it to the /etc/sysctl.conf:
xen.independent_wallclock = 1

Although, it is better if the Xen dom0 syncs the clock frequently so all the domains (domU) don’t need to do it by themselves and thus wasting resources. Why do things multiple times when it could be done just once.