Racker Hacker

It’s always been a bit of a challenge to disable TRACE and TRACK methods with Plesk. The only available options were to create a ton of vhost.conf files or adjust the httpd.include files and prevent modifications with chattr (which is a bad idea on many levels).

Luckily, Parallels has made things easier with a new knowledge base article.

I botched my upgrade to 2.3.3 for a short while (sorry for the errors!), but everything is back to normal now. There’s a critical XMLRPC vulnerability in 2.3.2, so you might want to upgrade soon!

If you’ve used newer versions of Horde with Plesk, you have probably noticed the news feed that runs down the left side of the screen. Depending on the types of e-mails you receive, you may get some pretty odd news popping up on the screen.

Luckily, you can remove the news feeds pretty easily. Open the following file in your favorite text editor:

/usr/share/psa-horde/templates/portal/sidebar.inc

Once the file is open, drop down to line 102 and comment out the entire if() statement (lines 102-117).

NOTE: If you upgrade Plesk, this change will most likely be reversed.

I had some time to do some testing of my blog’s performance today, and I discovered how much of a difference the WP-Cache plugin makes.

This blog runs on a server with dual Xeon Woodcrest CPU’s, 64-bit CentOS 4.5 and a 100mbit network connection. Here’s the first test with WP-Cache turned off:

$ http_load -parallel 10 -seconds 30 urltocheck.txt
346 fetches, 10 max parallel, 1.78616e+07 bytes, in 30 seconds
51623.2 mean bytes/connection
11.5333 fetches/sec, 595387 bytes/sec
msecs/connect: 15.1661 mean, 16.97 max, 14.922 min
msecs/first-response: 445.984 mean, 2328.82 max, 189.62 min
HTTP response codes:
code 200 — 346

346 fetches in 30 seconds is not a very exciting performance number for me. That’s just over 10 fetches per second, and on a busy day, I sometimes reach that number. Also, while this test ran, the server’s CPU usage was extremely high and over 80% of all four cores were in use. The iowait was about 20% across the board.

I decided to turn on WP-Cache and give it another go with the same test:

$ http_load -parallel 10 -seconds 30 urltocheck.txt
3482 fetches, 10 max parallel, 1.79671e+08 bytes, in 30 seconds
51600 mean bytes/connection
116.067 fetches/sec, 5.98904e+06 bytes/sec
msecs/connect: 15.2259 mean, 18.257 max, 14.891 min
msecs/first-response: 20.7297 mean, 69.39 max, 18.861 min
HTTP response codes:
code 200 — 3482

Wow, that’s a 10-fold improvement, and I can handle over 100 requests per second with 10 parallel requests. Also, the iowait dropped to 5%, and overall CPU usage remained under 8%.

I kicked it up to 20 parallel connections and tried again:

$ http_load -parallel 20 -seconds 30 urltocheck.txt
5817 fetches, 20 max parallel, 3.02176e+08 bytes, in 30 seconds
51947 mean bytes/connection
193.9 fetches/sec, 1.00725e+07 bytes/sec
msecs/connect: 17.9175 mean, 30.831 max, 14.911 min
msecs/first-response: 24.5352 mean, 97.475 max, 18.978 min
HTTP response codes:
code 200 — 5817

Almost 194 connections served per second! Also, the CPU usage was only at about 14% during the duration of the test.

I decided to tempt fate and see if I could blow the roof off the test with 50 parallel connections:

$ http_load -parallel 50 -seconds 30 urltocheck.txt
5794 fetches, 50 max parallel, 2.99718e+08 bytes, in 30 seconds
51729 mean bytes/connection
193.133 fetches/sec, 9.99059e+06 bytes/sec
msecs/connect: 43.286 mean, 63.878 max, 14.942 min
msecs/first-response: 68.967 mean, 202.854 max, 20.014 min
HTTP response codes:
code 200 — 5794

The performance suffered a bit, but the server was still pumping out almost 200 connections per second, and I’m okay with that. Well, unless anyone has a spare Cisco 11501 laying around that I could have. And, of course, one additional server.

Just as a sidenote, I installed Zend Optimizer v3.3 on the server and performance actually dropped by 1%-3% for each test. I found that a bit surprising.

I used http_load to perform the benchmarks after I found it on Caleb’s blog.

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.

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

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

On brand new Plesk 8.2.x installations or on servers that have been upgraded to Plesk 8.2.x, you might run into this error when you attempt to log into squirrelmail after it was installed via RPM:

Error opening /var/lib/squirrelmail/prefs/default_pref
Could not create initial preference file!
/var/lib/squirrelmail/prefs/ should be writable by user apache
Please contact your system administrator and report this error.

No matter what you do to the /var/lib/squirrelmail/prefs/default_pref file, even if you chmod 777 the file, you will still get the error. If you check the /etc/php.ini, you will normally find safe_mode set to on.

;
; Safe Mode
;
safe_mode = Off

Simply change safe_mode to off and reload Apache. If you try to log into squirrelmail again, it should complete successfully. I’ve tested this on Red Hat Enterprise Linux 4:

# rpm -q squirrelmail
squirrelmail-1.4.8-4.0.1.el4

I’ve seen quite a few situations where the Horde login process can take upwards of 45 minutes to log a user into the webmail interface. There’s a few issues that can cause these extended delays, and most of them can be fixed rather easily:

Too many filters / Giant whitelists and blacklists
This is the biggest cause that I’ve seen. Some users will create gigantic white and black lists (upwards of 5,000 is my record that I’ve seen) and this makes Horde compare each and every message in the inbox against these lists upon login. This also applies to filters as Plesk does not use sieve/procmail for mail delivery. Horde is forced to do all of the filtering upon login (in some versions) and this can cause extreme delays.

Mailbox is gigantic
I’ve seen Horde logins take quite a while in mailboxes that are over 500MB in size. If the size of your e-mails is large, and you have a large mailbox with fewer e-mails, Horde can normally work quickly. But, if your inbox is full of tiny e-mails, Horde takes a long time to fully index your mail and display the list (even though it only displays 25-30 at a time).

Too many users logged into Horde simultaneously
In my opinion, Horde’s CPU and memory requirements are too large for a webmail application. I’ve seen 30-40 simultaneous Horde sessions bring a dual-core box with 2-4GB of RAM and SCSI disks to its knees. Consider installing squirrelmail or roundcube webmail for some of your users and urge them to use it instead.

IOwait caused by something else
Sometimes the server can simply be bogged down with other requests from other daemons, and this slows Horde down. Make sure that your MySQL installation is tuned properly, and that users are not abusing scripts running through Apache.

Some users will want to parse HTML through the PHP parser because one of their applications requires it, or because they think it’s a good idea. Parsing regular static content through PHP is not recommended as it will cause a performance hit on the server each time a static page is loaded.

Unfortunately, enabling this in conjunction with Plesk will cause problems with the Plesk web statistics. Since the PHP parsing is disabled for the /plesk-stat/ directories, Apache will mark the page as a PHP page and your browser will attempt to download it rather than display it.

To fix this issue, simply add the following LocationMatch to the bottom of your Apache configuration:

AddType application/x-httpd-php .php .html

<LocationMatch "/plesk-stat/(.*)">
AddType text/html .html
</LocationMatch>

This will force Apache to serve HTML files from /plesk-stat/ as text/html rather than application/x-http-php. Your web statistics will display in the browser rather than downloading as a PHP file.