I therefore decided to implement an Ant Task for parsing TODOs in source code. You can read more about it over on the Google Code project. Please feel free to review code, suggest features or try it out and report a bug.

Happy new year to all; many happy returns.

See you in 2010!

What I’m Running

Here’s a rundown of what sites I’m running and the software used.

• beplacid.net – Apache 2, Django (Python framework), MySQL (one instance)
• blog.beplacid.net – PHP 5, MySQL, WordPress
• readingcamra.org.uk – Apache Tomcat 6, Java 5, MySQL
• readingbeerfestival.org.uk – As above

Wget – the Swiss army knife of HTTP command line tools

Wget’s one of those tools you really take for granted. It’s versatile, reliable, simple and most importantly – it does its job very well. One of its nicest features is the –mirror option. This allows you to…mirror a given website. I initially thought of running multiple instances of wget at the same time. I started small at first: one instance running to mirror the entire site. I ran the following in a shell:

alex@prometheus:/tmp$ wget –mirror beplacid.net/

It’s simple: mirror beplacid.net. Watching the processes and CPU usage on the server, it became apparent that  this wasn’t going to do much. The CPU usage didn’t exceed 5% on its first core. I had to rethink. Then ab sprung to mind.

ab – Apache benchmarking tool

This is another useful tool. It’s simple to use and allows you to quickly and easily hit a given hostname with HTTP requests, all tailored to your specific needs. To do all this, however, you need to be running as root. A noble security measure.

I wanted to generate some traffic that would put the server under some strain, so I started with 50 requests and 5 at a time:

prometheus:/root$ ab -n 50 -c 5 beplacid.net/

Now things started to get fun. This peaked CPU usage to 94% on one core, the others were between 60 and 80. I was starting to see some real stats. I doubled things – 100 with 10 per request:

 prometheus:/root$ ab -n 100 -c 10 beplacid.net/

This was a little more representative of a heavy amount of traffic. Perhaps akin to slashdot or a reddit. Put simply, that’s 100 requests with 10 each sent each time. Still nothing major, so I went all out:

Concurrency Level:      10
Complete requests: 1000
Total transferred:      4856792 bytes
HTML transferred:       4687792 bytes
Requests per second:    4.99 [#/sec] (mean)
Time per request:       2002.453 [ms] (mean)
Time per request:       200.245 [ms] (mean, across all concurrent requests)
Transfer rate:          23.69 [Kbytes/sec] received

To summarise, the server took 1000 requests with an average of 5 per second, each returning just over 2 seconds. Not bad, considering what I’m running.

I’m pleased with my setup. It can take a punch and it’s still running. My next task is to hit both beplacid.net and the blog, with perhaps some traffic mirroring readingbeerfestival.org.uk too.

Introduction
This HowTo explains the installation and configuration of Apache 2.2.3, Tomcat 5.5.25 and the Apache Jakarta module — a connector/proxy for Apache & Tomcat — under Debian Etch. It is geared towards those who already have experience configuring Apache and Tomcat and are aware of the basic principles behind Apache modules.

Prerequisites
A working installation of Debian GNU/Linux that has an internet connection, or valid CD-ROM apt packages disc.

Step 1: Installing Apache
If you don’t already have Apache installed, you will need to run the following in a shell as root:

This will install Apache 2 and any relevant dependencies. Configuration files for Apache can be found under /etc/apache2, and host-specific configuration are found under /etc/apache2/sites-available/. This is where you should configure your individual Virtual Hosts, as opposed to placing the configuration in /etc/apache2/apache2.conf.

Step 2: Install mod_jk
Using apt, you need to install the Apache Jakarta module by executing the following in a shell as root:

The module may need enabling via ‘a2enmod jk’, but it is not necessary at this time. Go ahead and execute the following as root:

Running the above should return a message similar to ‘Module enabled, now run /etc/init.d/apache2 force-reload’. I do not recommend reloading Apache’s configuration until everything has been installed and setup. This will ensure Apache remains usable while you setup Tomcat in the next step.

Step 3: Download and Extract Apache Tomcat 5.5.25
There’s a reason I installed Tomcat manually: Debian’s Tomcat package is a mess. The default package splits, amongst others, the webapps and conf folders. Whilst the conf folder is situated in a respectable location (/etc/tomcat5), the webapps directory is symlink’d under /var/, which tends to cause problems with Apache->Tomcat configuration. Therfore, I have chosen to manually install Tomcat using the .tar.gz from tomcat.apache.org; as well as this being a recommendation from various people in the #tomcat channel on irc.freenode.net. In short, it’s a configuration and administration nightmare.

Download Apache Tomcat 5.5.25 from here: http://tomcat.apache.org/download-55.cgi (select a mirror) and extract it to one of the following locations (I used /usr/share/):

• /usr/local/
• /usr/share/

To do the above, execute these commands as root:

Now, let’s setup a user and group so we can provide safe permission control over the conf and webapps directories.

Step 4: Add a tomcat user and group

We’ve just created the tomcat user & group, so let’s apply the ownership permissions to the webapps directory:

This now means that any user who’s in the tomcat group can read, write and execute files under the webapps directory.

Note: if you use a specific user and group such as www-data for Apache ownership and execution, which is the default in Debian, you will need to add ‘tomcat’ to the www-data user’s groups:

The following is optional, as it sets the group permissions of the server.xml to writable by the tomcat group. This may not be what you want, so be careful!

Now that we’ve setup the most important directories, let’s make the tomcat startup and shutdown bash scripts executable, ready for starting it up:

Step 4: Create the workers.properties File
Create the following file, as root, under /etc/apache2 or a directory of your choice (/usr/share/tomcat-5.5.25/conf would also be fine), but make sure it’s readable by the tomcat user and/or group.

The ‘worker.list’ parameter defines the names for the ajp13 connector(s). This is what Apache talks to. You can specify a name of your choice, but make sure you remember it for later, and ensure you’ve changed all parameters beginning with ‘worker.default’ to the name you’ve set.

Step 5: Configure an Apache to Talk To Tomcat and add a Virtual Host
This step is the most important part. It assumes that you’re using virtual hosts for Apache (you may not be), so if that isn’t the case, just place the JkMount configuration lines in the Virtual Host section along with the config. below in your main apache file (/etc/apache2/apache2.conf).

For my virtual host, I created the following configuration file under /etc/apache2/sites-available:

The most important lines in the above quote are the following:

These two lines specify the URL paths that should be handed to mod_jk and thus Tomcat. The ‘default’ section of the line specifies the JK worker identifier. This must match the name you specified in the workers.properties file!

That’s the configuration done, let’s fire this baby up!

Step 5: Unleashing the Beast; Starting Apache & Tomcat
To ensure a clean start up, I recommend stopping Apache entirely, and then starting up Tomcat, then Apache. Do so by executing the following commands (as root, see the note blow otherwise)::

Note: if you want tomcat to run as a separate user but keep ownership as root, use jsvc and the -user flag to specify the user it should change to at startup.

Both Tomcat and Apache should startup without error, and you should now be able to connect to Apache and the Tomcat via the specified Virtual Host.