Racker Hacker

Thanks to an e-mail from Joe Calderon, I’ve corrected a MySQLTuner bug where indexes were not being calculated properly when symbolic links are used. It was a quick fix, and the new version is now available for download.

Also, MySQLTuner now has a standardized versioning scheme. I’m starting at 0.8.0 since I’m close to a completely stable release. There’s still a few kinks when working with MySQL cluster nodes, and I’m hoping to work that out soon.

Thanks for downloading!

One of my biggest complaints on RHEL 4 is the large resource usage by the version of SpamAssassin that is installed. When it runs, it uses a ton of CPU time and causes a lot of disk I/O as well. When running top, you may see multiple spamd processes. For a high-volume e-mail server (like the one I administer), this is simply unacceptable.

I decided to do something about it, and here are the steps:

First, you will need two RPMs:
Latest SpamAssassin RPM from Dag
The psa-spamassassin RPM from SWSoft/Parallels.

Once you have them both on the server, install the new SpamAssassin package from Dag:

# rpm -Uvh spamassassin-(version).el4.rf.(arch).rpm

At this point, Plesk’s spamassassin scripts will be non-functional, but the next step will fix it:

# rpm -Uvh --force psa-spamassassin-(version).(arch).rpm

NOTE: DO NOT REMOVE the psa-spamassassin RPM. This will begin stripping your system of all SpamAssassin configurations and it cannot be reversed!

Plesk’s SpamAssassin scripts have been restored at this point in the process. Now, we need to do the part that really makes SpamAssassin work efficiently:

# sa-update; sa-compile;

This will update the SpamAssassin rules, and it will compile the rules with re2c (you may also need to get this RPM from Dag). This compilation means less disk access, and less CPU time being used to process e-mails.

To activate the compiled rules within SpamAssassin, uncomment the plugin line in /etc/mail/spamassassin/v320.pre:

# Rule2XSBody - speedup by compilation of ruleset to native code
#
loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody

Please bear in mind that this process is done at your own risk. This may cause issues getting support from SWSoft or your hosting company. This has been tested on Red Hat Enterprise Linux 4 64-bit with Plesk 8.1.1, 8.2.0, and 8.2.1 with SpamAssassin 3.2.3 and 3.2.4.

One of the questions I receive the most is: “What version of Plesk works with MySQL 5?” The minimum version of Plesk for MySQL 5 is 8.1.0. If you install MySQL 5 on a version prior to 8.1.0, you may be able to access then panel in the other 8.x versions, but your upgrades will fail miserably.

In case you’re curious about a slightly older system, full MySQL 4 support was available in Plesk 7.5.3. However, MySQL 4 is supported on some distributions as far back as 7.1:

Fedora Core 2
Mandrake 10
SuSE 9.0
FreeBSD 5.2.1

Check out SWSoft/Parallel’s site for more information about MySQL 4 and 5 support.

By setting a certain bash environment variable, you can limit which commands are kept in the .bash_history file. The following options can be passed to the HISTCONTROL environmental variable:

ignorespace - omits commands beginning with a space
ignoredups - omits commands that match the previously run command
ignoreboth - combines ignorespace and ignoredups
erasedups - removes previous lines that match the line that was just run

To set it, simply run the following from the command line, or add it to the .bashrc or a single user’s .bash_profile:

export HISTCONTROL=ignorespace

If no value is set, then all commands will be saved regardless of their content.

Installing new hardware may mean that new kernel need to be loaded when your server boots up. There’s a two step process to making a new initrd file:

First, add the appropriate line to your /etc/modules.conf or /etc/modprobe.conf which corresponds to your new kernel module.

Next, rebuild the initial ram disk after making a backup of the current one:

# cp /boot/initrd-`uname -r`.img /boot/initrd-`uname -r`.img.bak
# mkinitrd -f initrd-`uname -r`.img `uname -r`

Reboot the server now and make sure the new driver is loaded properly.

If you have a new Plesk installation and the following option is greyed out in Server -> Mail:

Switch on spam protection based on DNS blackhole lists

Just install the following RPM from Plesk:

psa-qmail-rblsmtpd

I’ve just reviewed the stats for MySQLTuner, and it crossed the 5,000 download mark last week! Thanks to all of you who have helped me make it a successful tool for MySQL server optimization.

With that said - how can MySQLTuner be improved to help you? Please let me know, and I’ll get started on those features!

Last week, I found myself with a server under low load, but it couldn’t make or receive network connections. When I ran dmesg, I found the following line repeating over and over:

ip_conntrack: table full, dropping packet

I’d seen this message before, but I headed over to Red Hat’s site for more details. It turns out that the server was running iptables, but it was under a very heavy load and also handling a high volume of network connections. Generally, the ip_conntrack_max is set to the total MB of RAM installed multiplied by 16. However, this server had 4GB of RAM, but ip_conntrack_max was set to 65536:

# cat /proc/sys/net/ipv4/ip_conntrack_max
65536

I logged into another server with 1GB of RAM (RHES 5, 32-bit) and another with 2GB of RAM (RHES 4, 64-bit), and both had ip_conntrack_max set to 65536. I’m not sure if this is a known Red Hat issue, or if it’s just set to a standard value out of the box.

If you want to check your server’s current tracked connections, just run the following:

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

If you want to adjust it (as I did), just run the following as root:

# echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max

I stumbled upon this peculiar bounce message recently while working on a server:

Hi. This is the qmail-send program at yourmailserver.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

Return-Path:
Received: (qmail 14418 invoked by uid 110); 9 Jan 2008 13:04:33 -0600
Delivered-To: 54-user2@domain.com
Received: (qmail 14411 invoked by uid 110); 9 Jan 2008 13:04:33 -0600
Delivered-To: 53-user1@domain.com
Received: (qmail 14404 invoked from network); 9 Jan 2008 13:04:33 -0600
Received: from otherdomain.com (HELO otherdomain.com) (11.22.33.44)
by yourmailserver.com with SMTP; 9 Jan 2008 13:04:33 -0600

Basically, this is qmail’s way of letting you know that your e-mails are stuck in a mail loop. One e-mail user is redirecting to another e-mail user, and that e-mail user is redirecting back to the first one. If q-mail already has a delivered to line which matches one that it already added, it bounces the e-mail and halts delivery.

You may catch this error when you attempt to start dovecot on a Red Hat Enterprise Linux 5.1 system with the 64-bit architecture:

dovecot: imap-login: imap-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory
dovecot: pop3-login: pop3-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory

If you start dovecot, the main dovecot daemon will run with one auth child process, but there will be no POP/IMAP processes started. To fix the issue, open the /etc/dovecot.conf and adjust the following directive:

login_process_size = 64

Restart dovecot after making the change:

# /etc/init.d/dovecot restart

This was tested on RHEL 5.1 x86_64.