Categories
How-To's

Compiling Courier 0.60.0 into RPMs for CentOS 5.2

In this article I will explain how to build RPM packages from the tar.gz packages on the Courier site in order to install Courier and/or its components using the RPM based installer in CentOS.

Server crashes always come when you least expect them. My trusty server just came down with a bad case of broken SATA controllers (don’t know how to cure that). Of course, the socket A cpu (Athlon 2600XP) motherboard is long out of fashion and so we wind up with the purchase of a new server (technically an HTPC but I’ll post something about that later on).

One of the key packages I use for years is Courier MTA. This software is supported fine by Gentoo but because the number of servers that I need to maintain is steadily growing, the drive for cutting edge kernels and software is fading as upgrading Gentoo systems can be a time consuming process.

So in the reinstall I decided to drop the mail, web and ftp services into a virtual CentOS machine so I could move the server to a different computer in case of the physical host failing.

The first thing that became obvious was the lack of Courier RPM’s out there, simply because the Courier package from the site can be converted into RPM’s with ease. If you are reading this then you probably have not compiled packages before and you need some help.

Disclaimer: I am using a setup which uses MySQL based authentication so I will remove the other database packages as soon as I am done – if you need those, be sure to omit those commands.

Start out by installing ‘rpmbuild’ as we will use it to build the packages:

yum install rpm-build

Next, get the latest source tarball from here.

As a normal user (running as root will give you an error so don’t bother) run the following:

rpmbuild –ta courier-0.60.0.tar.bz2

In my case I got this error telling me I don’t have enough permissions to write where the rpmbuild tool wants to put its files:

error: Failed to rename /usr/src/redhat/SPECS/rpm-spec.uykL0j to /usr/src/redhat/SPECS/rpm-spec.uykL0j: Permission denied: No such file or directory

This is a bother because Courier requires you to be non-root and rpmbuild requires you to be root. I solved this by temporarily changing the /usr/src/redhat owner to be me:

chown berend:users /usr/src/redhat –R

Running rpmbuild again now shows us a list of missing dependencies, in my case I had to install:

yum install expect libtool-ltdl-devel gdbm-devel pam-devel gnutls-devel mgetty-sendfax pcre-devel openssl-perl gamin-devel

One of the missing requirements is the ‘/usr/lib/ltdl.h’file – this is part of the libtool-ntdl-devel package. Another is ‘/usr/include/fam.h’ which is provided by gamin-devel.

The primary missing package however, is courier-authlib-devel. We can solve this by going back to the download page and downloading the courier-authlib tarball. After grabbing it, run rpmbuild on it:

rpmbuild –ta courier-authlib-0.61.1.tar.bz2

On my system the following was required to be able to build the RPM:

yum install libtool libtool-ltdl-devel openldap-devel mysql-devel zlib-devel postgresql-devel gcc-c++ redhat-rpm-config

Note that if you skipped installing the dependencies for courier itself, some of those packages are needed for courier-authlib as well.

After calling rpmbuild again on the courier-authlib tarball, the compiler should kick in and the build will complete on its own. After the build is complete, install courier-authlib-devel to be able to build Courier itself (you can later remove this if you don’t need it), you need to run this as root:

rpm –i /usr/src/redhat/RPMS/i386/courier-authlib-0.61.1-1.i386.rpm rpm –i /usr/src/redhat/RPMS/i386/courier-authlib-devel-0.61.1-1.i386.rpm

If did everything right, calling rpmbuild on the courier tarball will now fire up the compiler on courier itself, resulting in a neat pile of RPMs in ‘/usr/src/redhat/RPMS’ – most of which have self-explanatory names or are dependencies of each other.

Before installing Courier, lets clean up the mess we had to make to get here, run this as root again:

yum remove libtool libtool-ltdl-devel openldap-devel mysql-devel zlib-devel postgresql-devel gcc-c++ redhat-rpm-config gdbm-devel pam-devel gnutls-devel mgetty-sendfax pcre-devel openssl-perl gamin-devel courier-authlib-devel  chown root:root /usr/src/redhat –R

Note that we omit ‘expect’ from the remove command as it is needed by courier and its packages.

And there you have it, a complete guide to building your own Courier RPM packages on CentOS 5.2. All that is left is to actually install the RPM’s and set up Courier but that is beyond this little howto.

Categories
Linux / Gentoo Linux

Postfix Queues and Amavis trouble

After I had not received mail for a couple of days I suddenly started to receive postmaster errors from one of the servers I maintained. The message told me the mail could not be delivered. On further inspection it seemed that this was a problem because postfix could not connect to [127.0.0.1].

This meant of course that some daemon on the server was out for lunch and it was screwing up the mail deliveries. Using ‘postqueue -p’ to inspect the queues I found out that 4000 messages where packed up in the queue, filling her up to the maximum I allowed.

After running ‘postsuper -r ALL’ (which means, re-queue all messages for instant delivery) I tailed the ‘/var/log/mail.log’ file to find out that 20% of the messages got delivered and the rest wound up back in line.

One error that kept flashing by was: ‘TROUBLE in check_mail: parts_decode_ext FAILED: run_command (open pipe): Can’t fork at…’. It had something to do with the FileIO class. Now the message came from Amavis and in fact, amavisd is nothing more than a Perl framework, hooking all kinds of filters together. This means its memory hungry but won’t totally crash upon hitting the floor.

This explained why a part of the messages made it through: a few threads fitted in memory, allowing for completing the delivery, however most mail got rejected once again and returned faithfully to the waiting queue. Another inspection of the queue confirmed this: after 2 attempts 3200 messages where still there.

Then it dawned on me: I had not enabled the swap memory! After fixing this (and adding 1GB swap to the 256MB of RAM) and reloading Amavis I tried once again to requeue all mail. This time the mail got through the filters in one piece (and well within the memory boundaries). I wish all issues with servers were as simple as this ^-^.