Racker Hacker

Since AOL sends their users’ traffic through proxy servers, this can cause problems with Horde’s session handling in Plesk. The problem arises when the user’s IP changes during the middle of the session.

You may see an error message in Horde that looks like this:

Your Internet Address has changed since the beginning of your Mail session. To protect your security, you must login again.

You’ll normally have this variable in /etc/psa-horde/horde/conf.php:

# $conf['auth']['checkip'] = true;

You can disable this ip check functionality which breaks sessions for AOL users by setting it to false:

# $conf['auth']['checkip'] = false;

When you create a CSR and private key to obtain an SSL certificate, the private key has some internal data called a modulus. This is integral to the security of your SSL encryption, but for this specific post, we will focus on one specific aspect.

If your private key and certificate do not contain the same modulus, then Apache will sometimes refuse to start or it may not respond properly to SSL requests. You can check the modulus of your private key and SSL certificate with these commands:

# openssl rsa -noout -modulus -in server.key | openssl md5
# openssl x509 -noout -modulus -in server.crt | openssl md5

If the MD5 checksums match, then the certificate and key will work together. However, if they are different, then you cannot use them together. Generally, this means that you used the wrong CSR (that corresponded to some other private key) when you obtained/created your SSL certificate.

We all enjoy having the GoogleBot and other search engine robots index our sites as it brings us higher on search engines, but it’s annoying when some user scrapes your site for their own benefit. This is especially bad on forum sites as they’re always a target, and it can severely impact server performance.

To hunt down these connections when the spidering is happening, simply run this command:

netstat -plan | grep :80 | awk '{print $5}' | sed 's/:.*$//' | sort | uniq -c | sort -rn

The IP’s that are making the most connections will appear at the top of the list, and from there, you can find out which unwelcome spider is scraping your site.

Lots of PCI Compliance and vulnerability scan vendors will complain about TRACE and TRACK methods being enabled on your server. Since most providers run Nessus, you’ll see this fairly often. Here’s the rewrite rules to add:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

These directives will need to be added to each VirtualHost.

Further reading:
Apache Debugging Guide

This error completely stumped me a couple of weeks ago. Apparently someone was adjusting the Apache configuration, then they checked their syntax and attempted to restart Apache. It went down without a problem, but it refused to start properly, and didn’t bind to any ports.

Within the Apache error logs, this message appeared over and over:

[emerg] (28)No space left on device: Couldn’t create accept lock

Apache is basically saying “I want to start, but I need to write some things down before I can start, and I have nowhere to write them!” If this happens to you, check these items in order:

1. Check your disk space
This comes first because it’s the easiest to check, and sometimes the quickest to fix. If you’re out of disk space, then you need to fix that problem.

2. Review filesystem quotas
If your filesystem uses quotas, you might be reaching a quota limit rather than a disk space limit. Use repquota / to review your quotas on the root partition. If you’re at the limit, raise your quota or clear up some disk space. Apache logs are usually the culprit in these situations.

3. Clear out your active semaphores
Semaphores? What the heck is a semaphore? Well, it’s actually an apparatus for conveying information by means of visual signals. But, when it comes to programming, semaphores are used for communicating between the active processes of a certain application. In the case of Apache, they’re used to communicate between the parent and child processes. If Apache can’t write these things down, then it can’t communicate properly with all of the processes it starts.

I’d assume if you’re reading this article, Apache has stopped running. Run this command as root:

# ipcs -s

If you see a list of semaphores, Apache has not cleaned up after itself, and some semaphores are stuck. Clear them out with this command:

# for i in `ipcs -s | awk '/httpd/ {print $2}'`; do (ipcrm -s $i); done

Now, in almost all cases, Apache should start properly. If it doesn’t, you may just be completely out of available semaphores. You may want to increase your available semaphores, and you’ll need to tickle your kernel to do so. Add this to /etc/sysctl.conf:

kernel.msgmni = 1024
kernel.sem = 250 256000 32 1024

And then run sysctl -p to pick up the new changes.

Further reading:
Wikipedia: Semaphore (Programming)
Apache accept lock fix

With Plesk 7.5.x, a PHP upgrade to version 5 will cause some issues with Horde. These issues stem from problems with the pear scripts that Horde depends on.

To fix it, run these commands:

# pear upgrade DB
# cp -a /usr/share/pear/DB.php /usr/share/pear/DB/ /usr/share/psa-horde/pear/

Credit for this fix goes to Mike J.

Urchin sometimes takes it upon itself to do some weird things, and this is one of those times. If Urchin has archived a month of data, and then you ask Urchin to parse a log that contains accesses from that archived month, you’ll receive this ugly error:

Unable to open database for writing since it has been archived

To fix it, cd into /usr/local/urchin/data/[profile name]/ and unzip the YYYYMM-archive.zip files, then move the zip files out of the way. Make sure that the unzipped files are owned by the Urchin user and group. You should then be able to re-run your stats without a problem.

Credit for this fix goes to Google

Should you find yourself in the situation where you’ve forgotten the Urchin admin password, don’t worry. It’s easily reset with the following command:

cd util ./uconf-driver action=set_parameter table=user name="(admin)" ct_password=urchin

This will set the password to ‘urchin’, and then you can log into Urchin’s web interface and change it to a secure password. The credit for this fix goes to Urchin’s site.

When Urchin’s task scheduler fails, you’ll notice big gaps in your data within Urchin. If your logs rotate out before someone catches the problem, then your data is gone, and unless you have it backed up, you’re out of luck. I’ve scoured the internet (and Urchin gurus) and I’ve yet to find a complete explanation for the occasional death of Urchin’s task scheduler.

You’ll see the “Warning! Task scheduler disabled.” error in bright red print in Urchin’s configuration menu when you click the “Run/Schedule” tab. It appears right below the gleaming “Run Now” button. If you click “Run Now”, Urchin will tell you again that the task scheduler is disabled.

To correct the problem, completely stop Urchin as root:
# /etc/init.d/urchin stop
-- OR --
# /usr/local/urchin/bin/urchinctl stop

Now, change to the /usr/local/urchin/bin directory and run:
# ./urchinctl status

If the Urchin webserver is running, but the task scheduler isn’t (which is the most likely situation), run:
# ./urchinctl -s start
# ./urchinctl status
Urchin webserver is running
Urchin scheduler is running

You should be all set. Credit for this fix goes to Urchin’s site.

If you need a quick self-signed certificate, you can generate the key/certificate pair, then sign it, all with one openssl line:

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