This site works best in a real browser - Sysadmin

realpath script

nospam@example.com (Graham Cox) — Wed, 09 Apr 2008 10:35:25 +0100

One thing that always gets me is how to convert a given path - be it absolute, relative or whatever - into an absolute path on the filesystem. It turns out there's a perl module that can do exactly this, and so I've just rolled a tiny script that makes use of this and converts it's first parameter into a real path - an absolute path on the filesystem regardless of where it came from, and without any extra . or .. elements in there.

The script does require the File::PathConvert module to be installed before it will work, but then you can just drop it into /usr/local/bin or wherever and do magic with it exactly the same as dirname or basename.



#!/usr/bin/perl -w



use File::PathConvert qw(realpath);



if (@ARGV==0)

{

        print "Usage: realpath \n";

        exit();

}

my $in = $ARGV[0];

my $outpath = realpath($in);

print $outpath;

Compiling LDAP support for Apache 2.2.4

nospam@example.com (Graham Cox) — Thu, 03 May 2007 21:17:45 +0100

Apache 2.2.4 has bundled with it modules for managing authentication against an LDAP directory. Unfortunatly the obvious way to compile this doesn't actually work.

The obvious way is to us a configure line like this:



./configure --prefix=/usr/local/httpd --enable-mods-shared=all --enable-ssl --enable-so --enable-auth-digest --enable-authnz-ldap  --with-ldap --enable-ldap --with-ldap-sdk=openldap

Unfortunatly, this doesn't build APR or APR-Util with LDAP support, so when it comes to compile the module itself it fails.

What I had to do instead is build APR and APR-Util seperatly. Of course, doing so still didn't work properly for some reason. It turns out that you have to build APR and APR-Util seperatly, then build Apache telling it exactly where these two libraries can be found.

My full build script for it now looks like this:



#!/bin/sh



cd httpd

make distclean

./configure --prefix=/usr/local/httpd --enable-mods-shared=all --enable-ssl --enable-so --enable-auth-digest --enable-authnz-ldap  --with-ldap --enable-ldap --with-ldap-sdk=openldap --with-apr=./srclib/apr --with-apr-util=./srclib/apr-util



# Build APR and APR-util seperatly due to LDAP issues

cd srclib

cd apr

./configure --prefix=/usr/local/httpd --enable-threads --enable-other-child

make

cd ..

cd apr-util

./configure --prefix=/usr/local/httpd --with-apr=../apr --with-ldap-lib=/usr/local/openldap/lib --with-ldap-include=/usr/local/openldap/include --with-ldap=ldap

make

cd ..

cd ..



make

In addition, by doing it this way you need to make sure that you do a make install in both srclib/apr and srclib/apr-util in addition to just the apache source directory. Failing to do so will mean that the LDAP enabled APR and APR-Util won't be installed, and adding the LDAP modules into your httpd.conf will stop Apache from loading... You can tell you've done this if you get the error



httpd: Syntax error on line 110 of /usr/local/httpd/conf/httpd.conf: Cannot load /usr/local/httpd/modules/mod_ldap.so into server: /usr/local/httpd/modules/mod_ldap.so: undefined symbol: apr_ldap_info

or something similar when you try to load Apache.

GPG Key Autoresponder with Procmail

nospam@example.com (Graham Cox) — Fri, 10 Nov 2006 15:04:39 +0000

I have just set up my procmail config to automatically send out my GPG Public key to anyone who sends a specially crafted email to me. Because I use exim as my MTA, I receive emails that get sent to graham-*@ and graham+*@ as well as those simply sent to graham@.

Making use of this, I've put together a procmail rule that automatically responds to all emails sent to graham-gpgkey@grahamcox.co.uk. This rule simply automatically responds to the sender with an email containing my GPG Public key.

The procmail rule that does this is as follows:



:0

 ^To: .*graham-gpgkey@grahamcox.co.uk

{

        # Rewrite the header of the incoming mail

        # formail's -r flag makes it a reply to the incoming message

        # formail's -I flags add/replace headers in the original message

        :0 fhw

        | formail       -rI"Subject: My GnuPG public key" \

                        -I"X-Loop: $MY_ADDR"

        # Write the body of the outgoing mail

        :0 fbw

        | /usr/bin/gpg --armor --export <my id>



        # Send the email

        :0 w

         > 1

        ! -oi -t

}

Database migration

nospam@example.com (Graham Cox) — Thu, 28 Sep 2006 09:49:35 +0100

Migration of actual database across is something that was not working at all last time I tried it, and that I have managed to make work perfectly this time around.

In order to migrate a database from an older version of Postgres to a newer version, you need to do a dump and restore of the data. Unfortunatly, the pg_dump tool on Postgres 7.3 doesn't dump Schemas in a form that Postgres 8.1 will restore, and so if you do this you end up with all of your tables and functions in the Public schema instead of the schemas you put them in.

However, there is a simple way around this, and one that works very easy and even removes a step from the migration.

Before, I was attempting to do the migration as follows:
This assumes that you have already created the database and users prior to importing the data.



oldserver$ pg_dump -f database.sql database



newserver$ scp oldserver:database.sql .

newserver$ psql -d database -f database.sql

The new method that I have been using, that seems so far to work perfectly, is as follows:



newserver$ pg_dump -f database.sql -h oldserver -U graham database

newserver$ psql -d database -f database.sql

In order to do this, there are a few things that need to be done first. Namely,
# Allow newserver to access oldserver. I did this by just putting a whitelist entry in the firewall on oldserver.
# Allow newserver to access the Postgres databases on oldserver. This is done by editing pg_hba.conf
# Allow the user to log in remotely. This is done by the settings in pg_hba.conf, and by making sure the user has a password you know.

The trick here is that the pg_dump that comes with Postgres 8.1 knows how to dump data from an older version of Postgres, but it dumps it in a format that the newer version is able to import properly.

Subversion Migration

nospam@example.com (Graham Cox) — Thu, 28 Sep 2006 09:34:16 +0100

Subversion Migration has been relatively painless. The only difficult part turned out to be the bit that I always have trouble with - installing the Python bindings so that ViewVC and other tools will work with it.

When installing Subversion, you go through the standard set of steps - ./configure, make, make check, sudo make install. What you also have to do in order to get the subversion python bindings installed I keep having to go and dig up on the internet.

It is not downloading the pysvn package and installing that. This is either an alternative or an older version of what is actually included with Subversion and does not do the complete job that ViewVC needs from it.

Instead, what you have to do is the following:

From the Subversion source directory, execute



$ make swig-py

$ sudo make install-swig-py

As it happens, this is mentioned in the INSTALL for Subversion. However, it's a small section right at the bottom of the file that refers you to read a different file that gives you the instructions.

Software installation

nospam@example.com (Graham Cox) — Wed, 27 Sep 2006 13:46:48 +0100

The complete list of "core" software that I have installed on the new server is as below.
Core software is the list of Systems software that I have installed myself - it doesn't include things like SSH which, whilst is Systems software, was pre-installed on the system. It instead is the list of software for what the server is actually going to be doing.

Apache - 2.2.3 - Webserver
Subversion - 1.3.1 - Version control
PostgreSQL - 8.1.4 - Database
PHP - 5.1.6 - Web software
Asterisk - 1.2 - VoIP Server.

Out of all of these, the only one that I had to install an older version of was Asterisk. This was because the dialplan and config that I already have doesn't appear to work on the latest trunk version, and it was too much hassle to make it all work now. That's a project for the future.

Server Migration

nospam@example.com (Graham Cox) — Wed, 27 Sep 2006 13:41:39 +0100

My old server wasn't good enough for everything that I was doing on it. Given the huge list of things I was doing on it, this wasn't surprising. Where it wasn't good enough was when I was trying to get it to run PostgreSQL 8.1 instead of 7.3 that it came with.

As such, I have migrated across to a bigger server - the Servelocity Unlimited+ FC5 server - and started installing everything on there.

This is actually the second time I'm attempting this. The first time was a couple of weeks ago, and the server that I got had issues with it that meant I wasn't going to use it. I have now got a good server and got all the software installed and running.