How to use logrotate with Apache's Tomcat (and any other Java process)

Logrotate is an excellent utility for managing log files that can start grow into an unmanageble size, Tomcat's catalina.out is one such file.

Most of the solutions (scroll down to the 'Rotate the logs' section) for managing catalina.out, or other log files generated by Tomcat or any Java process for that matter, don't mention the copytruncate option:

Truncate the original log file in place after creating a copy, instead of moving the old log file and optionally creating a new one, It can be used when some program can not be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log file stays in place.

This basically means that you don't have to configure your logrotate script to restart Tomcat just so you can tidy up your log files - it trades off uptime against completeness of log records.

I found out about this from the Mission Data Blog in their post titled 'managing disk space with logrotate'. Is definitely worth taking a good look through the man page for logrotate to see if there are any other gems you can take advantage of for your setup.

Technorati Tags: logrotate, Tomcat, catalina.out, Andrew Beacock

One suggestion re: Forbidden access via Apache Proxies

If you are getting the following error when configuring Apache 2.2's proxy support (mod_proxy):

HTTP error code 403 Forbidden

then you might want to take a look inside the error.log for your site. If you see an error message like this:

[warn] proxy: No protocol handler was valid for the URL /SomeUrl.
If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

Then you might want to check that you have more than just mod_proxy enabled. Mod_proxy is more of a virtual module relying on other modules to perform the proxying work depending on the type required. A common mistake is to have enabled mod_proxy but not enabled mod_proxy_http.

With Ubuntu or Debian you can enable them with the following two commands:

a2enmod proxy
a2enmod proxy_http

Otherwise you will have to make manual symbolic links to them yourself.

Technorati Tags: Apache, mod_proxy, proxy, HTTP, 403, Forbidden, Andrew Beacock

A Capistrano recipe for restarting Apache 2 (on Linux)

Capistrano is the rather excellent tool for automating Rails application deployment. But it can do a lot more than just uploading Rails applications to live webservers. It's scripts are basically Rake scripts and so have the full power of Ruby behind then so you can pretty much write code to do anything that you want.

I wanted a way to reload the configuration for my Apache2 web server running on my home Ubuntu server. I found a post on Mongrel and Capistrano 2.0 by John Ward which showed a very nifty way to create Capistrano tasks for variants of the same base command.

My adapted version for controlling Apache is:

namespace :apache do
  [:stop, :start, :restart, :reload].each do |action|
    desc "#{action.to_s.capitalize} Apache"
    task action, :roles => :web do
      invoke_command "/etc/init.d/apache2 #{action.to_s}", :via => run_method
    end
  end
end

Add this code to your config/deploy.rb. This will add four new tasks to Capistrano which you can use to restart or reload Apache:

cap apache:stop
cap apache:start
cap apache:restart
cap apache:reload

Technorati Tags: Capistrano, Apache, Ubuntu, Ruby, Rails, Rake, John Ward, Andrew Beacock

Using Apache to display a list of available Subversion repositories

If you have setup Apache to be able to serve multiple Subversion repositories from one parent Subversion path then you are probably wondering if there is a way to display the list of repositories available in that parent directory.

By default Apache will give you a 403 permissions error reporting:

403 Forbidden

You don't have permission to access /parent-subversion-directory on this server.

To enable the repository listing you need to use the SVNListParentPath option (see "Listing available repositories in mod_dav_svn (server)" under "Enhancements and Bugfixes" in the 1.3 release notes) in the Apache virtual host setup.
Note: this will only work in Subversion 1.3 and higher.

Edit your Subversion Apache configuration file to add the SVNListParentPath On line, an example is given below:

# Subversion
<Location "/svn">
   DAV svn
   SVNParentPath /svn
   SVNListParentPath On
   SVNIndexXSLT "/svnindex.xsl"
</Location>

If you now visit http://some-website.com/svn you will see a page entitled "Collection of Repositories" with a listing of links pointing to each Subversion repository!

Technorati Tags: Subversion, SVN, Apache, Andrew Beacock

Supporting multiple Subversion (SVN) repositories with Apache

My previous posts about Subversion on Debian Linux (installing, configuring, backported packages) showed how I installed and configured my local repository that I use for my home projects. I also used these tutorials when installing Subversion at work.

After creating a couple of repositories for different teams (all within the base /svn directory) I noticed that my Apache configuration file was starting to look a little repetitive:

# Subversion - team A
<Location "/a">
    DAV svn
    SVNPath /svn/team-a
    SVNIndexXSLT "/svnindex.xsl"
</Location>

# Subversion - team B
<Location "/b">
    DAV svn
    SVNPath /svn/team-b
    SVNIndexXSLT "/svnindex.xsl"
</Location>

I plan on creating at least two more repositories for other teams and so this was repetition was starting to bother me. A colleague pointed out that SVNParentPath (scroll about 1/4 down) should be the solution.
I rewrote my conf file to be the following:

# Subversion
<Location "/svn">
    DAV svn
    SVNParentPath /svn
    SVNIndexXSLT "/svnindex.xsl"
</Location>

Now any repositories that are created within the parent /svn directory will be available via http://some-url/svn/<repository name>, so my existing repository become:

http://some-url/svn/team-a
http://some-url/svn/team-b

Technorati Tags: Subversion, Debian, Linux, Andrew Beacock

Problems with Trac and backported Subversion on Debian Linux

After installing the backported package of Subversion last week and importing a pre-existing codebase into it I decided that now was a good time to put Trac on the server.

Following my previously blogged Trac installation & configuration guides I was able to get Trac up and running fairly smoothly with one small problem: the "Browse Source" button was failing reporting some issue with "svn" being an unknown repository type.

After some searching and thinking I realised that this was most probably due to conflict between the newer backported version of Subversion and the older Python Subversion bindings libraries.

Here's how I resolved this issue:

apt-get remove python2.3-subversion
apt-get install python-subversion

Refreshed my browser and everything worked correctly!

Technorati Tags: Andrew Beacock, Trac, Subversion, Python, Backports, Debian

Installing Subversion 1.3.2 using Backports on Debian (Sarge) Linux

Following on from my previous posts about installing Subversion from source, here are some notes on how to do it using backported Debian packages.

Add the following lines to your sources.list file in /etc/apt:

# backports
deb http://www.backports.org/debian sarge-backports main contrib non-free

Update your Apt sources list:

apt-get update

Uninstall any old Subversion packages:

apt-get remove subversion
apt-get remove libsvn0

Install Subversion with 1.3.2 as a specific version (this causes the backported version to override the stable version):

apt-get install libsvn0=1.3.2-5~bpo1
apt-get install subversion=1.3.2-5~bpo1

Check that the installed Subversion is the right one by using svn --version you should get something like:

svn, version 1.3.2 (r19776)
compiled Aug 12 2006, 12:05:49
...

Install the Apache2 Subversion modules:

apt-get install libapache2-svn=1.3.2-5~bpo1

Follow my instructions on Configuring Subversion (svn) on Linux (Debian Stable).

There you go!

Technorati Tags: Andrew Beacock, Subversion, Backport, Debian, Linux

Upgrading Subversion (svn) to 1.3.2 on Linux (Debian Stable)

I upgraded my Subversion repository tonight from 1.2.1 to 1.3.2 and it was an absolute breeze!
I followed the Subversion installation instructions that I've blogged about before (using the newly downloaded 1.3.2) ignoring the bit about installing Apache.

Ran through the usual Linux make, make install stuff, restarted Apache and accessed the repository browser webpage which displayed the updated version number at the bottom.

Couldn't have been simpler!

Technorati Tags: Subversion, Debian, Linux, Andrew Beacock

Creating a Trac instance on Debian Linux

In a post back in October (has it really been that long?) I walked through how to install Trac on Debian Linux. This post will cover the configuration of Trac so that at the end you will have a running Trac system that you can use as a wiki, ticket manager and Subversion repository browser.

First you need to decide where you want your Trac instance to live, I wanted mine to be accessible via a sub-section of a website, but I wanted the instance to live outside of that website's directory structure. I decided on /var/www/Trac which I would link to from within my other website.

To create the instance run the trac-admin command as the root user like so:
trac-admin /var/www/Trac initenv

It will now ask you a number of questions about your environment and project:
* Project Name - enter a human-readable name for your project, this will appear on emails, webpages, etc.
* Database connection string - just hit return to use the default SQLite
* Path to repository - the directory path to your Subversion repository, note: it cannot be a remote repository with the current version of Trac.
* Templates directory - just hit return to use the default templates directory.

If all went well it should report that the environment was created successfully and will give you instructions on how to quickly test that it's working.

Now that we have created the Trac instance, we need to configure Apache to make the site available to the outside world (or intranet if that's more relevant to you). I've set it up to be accessed via a www.somedomain.com/trac so I added the following stanza to that site's virtual host entry within the /etc/apache2/sites-available directory:

# trac
ScriptAlias /trac "/usr/share/trac/cgi-bin/trac.cgi"
<Location "/trac">
        SetEnv TRAC_ENV "/var/www/Trac"
</Location>

# edit trac.ini to change /trac to /trac-static
Alias /trac-static "/usr/share/trac/htdocs"

<Location "/trac">
        AuthType Basic
        AuthName "Trac"
        AuthUserFile /some/path/htpasswd
        Require valid-user
</Location>

This sets up /trac to point to the Trac master CGI script, and tells the script that the instance lives in /var/www/Trac. The htpasswd file protects the whole site from unauthorised people, (make sure that the htpasswd file exists and has some users in it otherwise you won't be able to access your Trac instance).

Before you restart Apache to see your new Trac instance you need to ensure that the Trac directory structure is owned by the same user as Apache, in my case www-data. Simply run chown -R www-data:www-data /var/www/Trac to sort this out.

Now restart Apache, (/etc/init.d/apache2 reload) and then goto http://www.yourdomain.com/trac to see Trac in all it's glory.

There are loads of things that you can configure with Trac and general usage instructions are all available within your instance, just click 'Help/Guide' link in the top-right menu bar.

I hope this has been informative, if you have any questions or comments then please don't forget to leave a comment or trackback below!

Technorati Tags: Trac, Apache, Subversion, Debian, Andrew Beacock

Configuring Subversion (svn) on Linux (Debian Stable)

My last post documented how to install Subversion. This post will cover the resulting configuration of Apache, plus the creation of the initial repository.

When you install Subversion, it adds two LoadModule lines to /etc/apache2/httpd.conf. This is not wanted as the Debian version of Apache2 installs things slightly differently from the default Apache (httpd.conf is not used, all this configuration now lives in apache2.conf, plus the loading of modules is done differently). edit /etc/apache2/httpd.conf and remove the 2 uncommented LoadModule lines.

Debian loads modules a little differently that the default Apache2. It lists the available modules as individual configuration files within a mods-available directory, then enables these by linking to them from a mods-enabled directory.

We need to create the two required module configuration files that are required by Subversion (we just removed them from /etc/apache2/httpd.conf!):

cd /etc/apache2/mods-available
echo "LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so" > dav_svn.load
echo "LoadModule authz_svn_module /usr/lib/apache2/modules/mod_authz_svn.so" > authz_svn.load

Now we need to enable them so that Apache will load them when it restarts:

cd ../mods-enabled
ln -s ../mods-available/dav.load
ln -s ../mods-available/dav_svn.load

That's the modules configured, now we need to create the Subversion virtual host entry that will point to our Subversion repository. Again, Debian does things a little different with virtual hosts, it has them listed as separate virtual host configuration files in sites-available and then enables them in sites-enabled:

cd /etc/apache2/sites-available

Due to Blogger being a pain when it comes to trying to post details containing lots of <'s and >'s, I'm including a link to an almost-copy of my Subversion virtual host configuration file. As you can see, it points the WebDAV & Subversion modules at /var/svn which will be the root of our repository, and uses Apache's htpasswd authentication to validate access.

Now we need to make the Subversion site available to Apache:

cd ../sites-enabled
ln -s ../sites-available/svn

Ok, that's Apache all done and dusted, now we just have to actually create the repository and then we are done.

The repository must be 'owned' by the same user that Apache runs as, otherwise read/write access may be blocked and all sorts of strange problems can occur, Debian runs Apache as user www-data by default:

mkdir /var/svn
chown www-data:www-data /var/svn

Now that the repository's root directory has been created, it's best to be the same user as Apache when creating the repository to ensure the files are created with the correct permissions:

su – www-data
svnadmin create /var/svn

That's the repository created, now we need to restart Apache to let the WebDAV & Subversion modules know that the repository is now available:

/etc/init.d/apache2 reload

If you now point your browser at http://svn.yourdomain.com you should see a web view of your new repository...what's that? It's asking for a username and password? Oh yes, we need to create any required users via the Apache htpasswd utility:

cd /etc/apache2
htpasswd -c svn.htpasswd your_username

Ok, try that URL again, you should be able to login and see a rather basic view of an empty Subversion repository. There is a slightly nicer skin that can be applied to Subversion to make the repository view cleaner, it's tucked away in the /usr/local/src/subversion-1.2.1/tools/xslt directory. These XSL and CSS files need to be added to the virtual host's document root, but as you may have noticed the DocumentRoot is the root of the Subversion repository. This means that you just have to import the two files into Subversion for the changes to take effect:

cd /usr/local/src/subversion-1.2.1/tools/xslt
svn import svnindex.xsl http://svn.yourdomain.com/svnindex.xsl -m "Improved web interface."
svn import svnindex.css http://svn.yourdomain.com/svnindex.css -m "Improved web interface."

Now revisit that URL again, and it should be a slightly nicer view of the repository, now with two files in it, svnindex.xsl and svnindex.css.

That's it, the repository is fully available to any user that you have created an htpasswd entry for in /etc/apache2/svn.htpasswd and who has a suitable Subversion client (TortoiseSVN and RapidSVN are two that I have used).

For full documentation on how to really use Subversion, please take a look at the O'Reilly Version Control with Subversion online book or buy the rather excellent book Pragmatic Version Control Using Subversion by Mike Mason.

Please let me know if you found this post (and the last one on how to install Subversion) useful, if so I might start to blog about Subversion even more...

UPDATE: I've moved some files around on my server, I've not changed any of the content of this post.

Technorati Tags: Subversion, Debian, Apache, Mike Mason, Andrew Beacock

Installing Subversion (svn) on Linux (Debian Stable)

This post details my recent install of Subversion 1.2.1 on Debian Stable. The Debian packaged version of Subversion is currently only 1.1.4, but I wanted to install the latest version as it supports full WebDAV autoversioning & has the FSFS repository back end as the default.

I wanted to access Subversion via the WebDAV protocol, this requires Apache2. As Debian Stable only recently included the apache2 package, I had to update to that version first.

Note: all these commands were run as the root user.

Install Apache2:

apt-get install apache2

That installs the web server and all the required packages, it does not start Apache by default, you need to edit /etc/default/apache2 and change NO_START to 0, then run /etc/init.d/apache2 start to get the basic web server running.

When you build Subversion from source, it requires the apxs2 tool to be able to build and install the Subversion extension modules. This is hidden away in the apache2-threaded-dev package, it's not available in any other package:

apt-get install apache2-threaded-dev

Now we need to download, build and install Subversion. Download Subversion 1.2.1 and save it in /usr/local/src

Unpack Subversion:

tar zxvf subversion-1.2.1.tar.gz
cd subversion-1.2.1

We now need to ensure that all build dependencies are taken care of, plus let the build scripts know where the apxs2 tool is located (it's in a non-standard place with Debian):

./configure --with-apxs=/usr/bin/apxs2

Build Subversion:

make

Run the unit tests to ensure that the built version is a valid release (note: this can take quite a while - well at least it does on my poor Celeron Linux server!):

make check

Install the Subversion binaries and libraries to the correct places:

make install

OK, that's Subversion installed, but it's not available yet, we still need to config access to it via Apache, and create the initial code repository. Please see my next post on how to do this...

Technorati Tags: Subversion, Debian, Apache, Andrew Beacock