Racker Hacker

Thanks to Oden Eriksson at Mandriva, MySQLTuner is now packaged into an RPM for easier installations on Mandriva Linux.

More data can be found in the Mandriva Linux Archives.

As an aside, I find it quite interesting that the first package for my script popped up on Mandriva. My first adventure into Linux was with Mandrake many years ago.

After I was asked to create a stored procedure on a MySQL 5.0.45 installation last week, I received the following error:

ERROR 1146 at line 24: Table 'mysql.proc' doesn't exist

The server had the default MySQL 4.1.20 that comes with Red Hat Enterprise Linux 4, and it was upgraded to MySQL 5.0.45. After the upgrade, the mysql_upgrade script wasn’t run, so the privilege tables were wrong, and the special tables for procedures and triggers did not exist.

To fix the problem, I ran:

# /usr/bin/mysql_upgrade

After about 20 seconds, the script completed and I was able to add a stored procedure without a problem.

There’s a few issues with PHP 5.2.5 and the version of Horde that is bundled with Plesk 8.1.x and 8.2.x. The PHP include paths that appear in the Apache configuration generated by Plesk conflict with the PHP installation, and that causes the Horde webmail interface to segmentation fault.

To fix the problem, create a file called /etc/httpd/conf.d/zz050a_horde_php_workaround.conf and put the following inside it:

<DirectoryMatch /usr/share/psa-horde>
php_admin_value include_path "/usr/share/psa-horde/lib:/usr/share/psa-horde:/usr/share/psa-horde/pear:."
</DirectoryMatch>

Reload the Apache configuration and your Horde installation should work properly with PHP 5.2.5.

Credit for this fix goes to Kevin M.

One of my biggest beefs with Plesk’s e-mail handling is the lack of server-side filtering. Plesk will only allow you to throw away e-mails marked as spam, but this won’t work for me since SpamAssassin marks some mails as spam that actually aren’t. If you set up filters in SquirrelMail or Horde, the filters will only work if you always log into the webmail interface to snag your e-mail.

Luckily, you can do some fancy work with procmail to have the filtering done server-side.

First, make sure procmail is installed on your server, and change to this directory:

/var/qmail/mailnames/yourdomain.com/yourusername/

Inside that directory, drop in a .procmailrc file which contains the following:

MAILDIR=/var/qmail/mailnames/yourdomain.com/yourusername/Maildir
DEFAULT=${MAILDIR}/
SPAMDIR=${MAILDIR}/.Junk/
:0
* ^X-Spam-Status: Yes.*
${SPAMDIR}

Once that file is in place, move the .qmail file out of the way, and replace it with this:

| /usr/local/psa/bin/psa-spamc accept
|preline /usr/bin/procmail -m -o .procmailrc

Please be aware that these changes will disappear if you make any adjustments to your mail configuration within Plesk. To get around this annoyance, just change the file attributes to immutable:

# chattr +i .qmail .procmailrc

Credit for this trick goes to Russ Wittmann.

There may be some situations where you want to encrypt FTP traffic with SSL certificates rather than using SFTP with SSH. Using vsftpd with SSL encryption is quite easy, and here’s how it’s done:

First, you’ll need to make a new self-signed SSL certificate (if you don’t have a key and certificate available already):

openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout server.key -out server.crt

Once you have the key and certificate made, you’ll need to concatenate them into a PEM file:

# cat server.key > /etc/vsftpd/server.pem
# cat server.crt >> /etc/vsftpd/server.pem

Now, simply adjust the vsftpd configuration file to enable SSL encryption:

ssl_enable=YES
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=YES
rsa_cert_file=/etc/vsftpd/server.pem

Once that’s complete, restart vsftpd and you will be able to connect to your FTP server using SSL/TLS encryption.

Further Reading:
Manpage of vsftpd.conf

In the US, we celebrate Thanksgiving today. I’m taking off the rest of this week, but you can expect updates to begin again on Monday!

If your system abruptly loses power, or if a RAID card is beginning to fail, you might see an ominous message like this within your logs:

EXT3-fs error (device hda3) in start_transaction: Journal has aborted

Basically, the system is telling you that it’s detected a filesystem/journal mismatch, and it can’t utilize the journal any longer. When this situation pops up, the filesystem gets mounted read-only almost immediately. To fix the situation, you can remount the partition as ext2 (if it isn’t your active root partition), or you can commence the repair operations.

If you’re working with an active root partition, you will need to boot into some rescue media and perform these operations there. If this error occurs with an additional partition besides the root partition, simply unmount the broken filesystem and proceed with these operations.

Remove the journal from the filesystem (effectively turning it into ext2):

# tune2fs -O ^has_journal /dev/hda3

Now, you will need to fsck it to correct any possible problems (throw in a -y flag to say yes to all repairs, -C for a progress bar):

# e2fsck /dev/hda3

Once that's finished, make a new journal which effectively makes the partition an ext3 filesystem again

# tune2fs -j /dev/hda3

You should be able to mount the partition as an ext3 partition at this time:

# mount -t ext3 /dev/hda3 /mnt/fixed

Be sure to check your dmesg output for any additional errors after you’re finished!

Apparently, a recent Red Hat Enterprise Linux update for ES3, 4 and 5 caused some Perl applications to throw errors like these:

unable to call function somefunction on undefined value

Of course, replace somefunction with your function of choice. To correct the issue, you can force CPAN to bring back a more sane version of Scalar::Util:

# perl -MCPAN -e shell
cpan> force install Scalar::Util

A few days ago, I stumbled upon a server running qmail with qmail-scanner. The server was throwing out this error when a user on the server attempted to send an e-mail to someone else:

451 qq temporary problem (#4.3.0)

The one thing I love about qmail is its extremely descriptive error messages. Did I say descriptive? I meant cryptic.

Luckily, clamdscan was a bit more chatty in the general system logs:

Nov 12 10:21:17 server X-Antivirus-MYDOMAIN-1.25-st-qms: server.somehost.com119488087677512190] clamdscan: corrupt or unknown clamd scanner error or memory/resource/perms problem - exit status 512/2

Okay, that helps a bit, but this one from /var/log/clamd.log was the big help:

Mon Nov 12 12:20:29 2007 -> ERROR: Socket file /tmp/clamd.socket exists. Either remove it, or configure a different one.

I removed the /tmp/clamd.socket file and clamd began operating properly after a quick restart of the clamd service. This one was pretty easy, but it was not well documented (as I discovered from a little while of Google searching).

By default, Red Hat Enterprise Linux 4 sets the default character set in Apache to UTF-8. Your specific web application may need for the character set to be set to a different value, and the change can be made fairly easily. Here’s an example where the character set is changed to ISO-8859-1:

First, adjust the AddDefaultCharset directive in /etc/httpd/conf/httpd.conf:

#AddDefaultCharset UTF-8
AddDefaultCharset ISO-8859-1

Then, reload Apache and check your headers:

# /etc/init.d/httpd reload
# curl -I localhost
HTTP/1.1 403 Forbidden
Date: Thu, 08 Nov 2007 22:18:14 GMT
Server: Apache/2.0.52 (Red Hat)
Accept-Ranges: bytes
Content-Length: 3985
Connection: close
Content-Type: text/html; charset=ISO-8859-1

This was tested on Red Hat Enterprise Linux 4 Update 5