Info
bogofilter
validrcptto
This patch requires some scripting to be of any real use. If your
system were to work off /etc/aliases alone you could probably get away
with just linking /var/qmail/control/validrcptto.cdb to the aliases.cdb.
If not you will need something else. For my own use, I have devised
these scripts. link9 and myself are backup MX records for each other. To
begin with the validrcptto patch was not that common and we got away
using catchalls that point to /dev/null, but not these days.
| locallist | perl script to create a cdb of all the local user accounts |
| merge | perl script to compile all the available host cdbs into a single file (the validrcptto.cdb) |
| local_update | bash script to announce update the other boxe(s) with its latest local user file |
As you can see these parts keep the cluster hosts happy.
The validrcptto patch is available from John Simpson's page, validrcptto.cdb
usage
You must create a directory to receive the cdb files from other cluster members, such as /var/qmail/validsmtproutes, and a directory to contain the last generated version of the locallist, /var/qmail/validsmtproutes/last for example. When the locallist runs, it will update the parent directory (validsmtproutes) with the latest copy, then, localupdate will do a diff on the two files to determine if the other cluster nodes need an update. If the update is required scp will do the distribution. This will not be compiled in until the next cycle at the destination node of localupdate.sh.
backups
In the past I have found it teadious to simply backup the whole ~vpopmail/domains directory. I know it's possible, but well, sometimes you might not want to restore the whole structure back to /home/vpopmail as that might not be where you're restore system holds the directories. For this reason, and a couple of other admin requirements I have devised a script to handle the backup process. This script is designed to backup each subdirectory of /home/vpopmail/domains to a compressed tarball.
Once compressed the file is copied to a desginated box via a hostname user.
After much thought, backups should be given a level of security. There is no reason why you should trust a backup server to be secure. Many people, (including myself!) have neglected to give any protection to backup data.
Some thought should be given to checking for disk space after the tar command has finsihed. It is not uncommon for a administrator to forget disk checking. This is however, another project in itself. Previously I would keep 7 days worth of backup locally, however due to growth it is only possible to keep one day's full backup locallly!
There are alternatives such as backing up files with a modification of one day, sounds reasonable enough? But what about file deletions, file moves etc? It could be possible
In the perl (future) version I will do some tricks to keep a monitor on the disk and CPU states. Not that this is not possible in the shell script version, it just makes more sense to do this in a threaded way.
| vpopmailbackup.sh | Perl version, TBA |
compression
The compression method that is used in the backup script is highly important, for the choice could effect the performance of your mailbox server for your clients.
Tests: tar -zcvf, tar -jcvf on a single 20meg file of random data $ time tar -cjvf datafile.tar.bz ./datafile /datafile
real 0m17.832s user 0m14.281s sys 0m0.248s $ ls -al datafile.tar.bz -rw-r--r-- 1 ed ed 21064552 2006-07-12 19:02 datafile.tar.bz
$ time tar -czvf datafile.tar.gz ./datafile ./datafile
real 0m4.560s user 0m1.790s sys 0m0.086s $ ls -al datafile.tar.gz -rw-r--r-- 1 ed ed 20974971 2006-07-12 19:03 datafile.tar.gz
So, as we see here, the compression is better on the random data when gzip is in use. I am aware that the random data is not a brilliant example, since maildirs could contain a greater portion of regular, 7bit ASCII, but I think this speaks for itself. There is just a smaller advantage to using bzip/2, such as the 5-10% smaller output, but really, this does not make up for the larger duration that the compression has to run. The backup of 15gigs of Maildir previously took 18 hours on a laden server, after reverting to gzip the backup now finishes in four hours.
network stats
This is perhaps the wrong category for network monitoring, but it's too small to go in a category of it's own. This code is justified by it being slightly related in that sometimes one wishes to know how much traffic one's mail server is sending/receiving. This used to be a single .c file which would pull the values from bsd interfaces. I then did an almost duplicate for linux /proc/net file system to get values from there too. More recently I have merged the two into a single program, which compiled on a BSD platform will pull values from BSD interfaces and do likewise on a linux platform. Since I don't have access to other platforms I cannot make it more portable.
tar zxvf netmon-0.01.tar.gz
| linux | make linux ./netmon |
| openbsd | make openbsd ./netmon |
| download | netmon |
is everything ok?
Fault finding can be tough, especially when one has to reproduce the error very quickly. Having experienced this problem often I have created a script to send a small attachment to mymailbox via each of the mailservers. It's surprising how much time it saves.
mailtest.pl
count recipients
This script just allows one to count the number of recipients that an email address has created. It's a common procedure for some customers to abuse their privileges somewhat and spawn many messages, sometimes with a single large attachment. This costs their bandwidth once, but yours perhaps whatever the maxrcptto value is.
In order to prove a case I had to collect these values from the server, I did so using this script. I hope it can be of use to yourself also.
count_recps.pl
processes
Not related to qmail, but it's been fun to work on. This program allows anyone to cycle the process list on a linux 2.6 kernel. Any number of things could be tied into this to create a multitude of MRTG graphs! The intention of this program is to give some abstraction and eventually I shall work some BSD functionality into this.
This is not tested anywhere other than my workstation computer that runs the 2.6.17 kernel. I assume there are going to be some differences in the stat_info structure between kernel versions. There is very little that can be done about this.
processes.tar.gz