Racker Hacker

I saw a ticket the other day where a customer received this error from Horde when trying to expand items on the left pane of the interface:

Fatal error: Cannot use string offset as an array in /www/horde/lib/Horde/Block/Layout/Manager.php on line 389

It turns out that Plesk 8.1.1 bundles Horde 3.1.3 which has an occasional bug within the interface. Upgrading to Plesk 8.2.0 corrects the issue as Horde 3.1.4 is installed with the upgrade.

See Horde’s bug page for more information.

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.

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 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.

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 stumbled upon a server running Plesk 8.2.1 where a certain user could not receive e-mail. I sent an e-mail to the user from my mail client, and I never saw it enter the user’s mailbox. It didn’t even appear in the logs.

After checking the usual suspects, like MX records, mail account configuration, and firewalls, I was unable to find out why it was occurring. Even after a run of mchk, the emails would not be delivered.

I began testing with a telnet connection to the SMTP port:

$ telnet 11.22.33.44 25
Trying 11.22.33.44...
Connected to 11.22.33.44.
Escape character is '^]'.
220 www.yourserver.com ESMTP
HELO domain.com
250 www.yourserver.com
MAIL FROM: test@test.com
250 ok
RCPT TO: someuser@somedomain.com
421 temporary envelope failure (#4.3.0)
QUIT
221 www.yourserver.com
Connection closed by foreign host.

Temporary envelope failure? I was still confused. After reviewing the logs, I found the following line whenever I tried to telnet to port 25 and send an e-mail:

Dec 2 00:15:49 www relaylock: /var/qmail/bin/relaylock: mail from 44.33.22.11:17249 (yourdesktop.com)

It turns out that the customer was using greylisting in qmail with qmail-envelope-scanner. After a quick check of /tmp/greylist_dbg.txt, I found the entries from me (as well as a lot of other senders), and that ended up being the root of the 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.

I found myself wrestling with a server where the Plesk interface suddenly became unavailable without any user intervention. An attempt to start the service was less than fruitful:

[root@server ~]# service psa start
Key file: /opt/drweb/drweb32.key - Key file not found!
A path to a valid license key file does not specified.
Plesk authorization failed: HTTP request error [7]
Error: Plesk Software not running.
                                                           [FAILED]

(Although I included the text from the drweb failure, I later found that it was not related to the issue. However, since it might appear in your logs prior to the HTTP request error, I included it anyways.)

This was a perfectly working server that had no other issues besides this peculiar Plesk issue. Another technician had upgraded the license a few weeks prior, and it was verified at the the time to be working properly. After a bit of Google searching, I found that the solution was to completely stop Plesk and its related services and then start it all up again.

[root@server ~]# service psa stopall
/usr/local/psa/admin/bin/httpsdctl stop: httpd stopped
Stopping Plesk:                                            [  OK  ]
Stopping named:                                            [  OK  ]
service psa startStopping MySQL:                           [  OK  ]
Stopping : Stopping Courier-IMAP server:
   Stopping imap                                           [  OK  ]
   Stopping imap-ssl                                       [  OK  ]
   Stopping pop3                                           [  OK  ]
   Stopping pop3-ssl                                       [  OK  ]

Stopping postgresql service:                               [  OK  ]
Shutting down psa-spamassassin service:                    [  OK  ]
Stopping httpd:                                            [  OK  ]

[root@server ~]# service psa start
Starting named:                                            [  OK  ]
Starting MySQL:                                            [  OK  ]
Starting qmail:                                            [  OK  ]
Starting Courier-IMAP server:
   Starting imapd                                          [  OK  ]
   Starting imap-ssl                                       [  OK  ]
   Starting pop3                                           [  OK  ]
   Starting pop3-ssl                                       [  OK  ]

Starting postgresql service:                               [  OK  ]
Starting psa-spamassassin service:                         [  OK  ]
Processing config directory: /usr/local/psa/admin/conf/httpsd.*.include
/usr/local/psa/admin/bin/httpsdctl start: httpd started
Starting Plesk:                                            [  OK  ]
Starting up drwebd:                                        [  OK  ]

I couldn’t nail down anything within the Plesk log files that would explain the cause of the problem, but this solution corrected the issue instantly.

This issue occurred with Plesk 8.1.1 on Red Hat Enterprise Linux 4 Update 5