Panache and Peril with Plesk

Submitted by Morbus Iff on Sun, 2007-02-04 20:22

With this new dedicated server, I chose Plesk as a control panel solely because I hated it less than Ensim or cPanel. Normally I'd do all the installation, configuration, and tweaking of a server myself, but I just don't have time for that anymore. The biggest problem I have with control panels is that they make it very hard to do manual configs the normal Linux way: changes either get overwritten or ignored. Plesk is a little easier to live with in this regard; what follows are my last mile tweaks.

While Plesk allows you to create a chrooted FTP user for a domain, it doesn't have a front end for adding another, much less one constrained a particular subdirectory of that domain. Plesk's configuration of ProFTPD chroots any user with a group of psacln. Via the shell, just useradd a new user with the desired home directory, use /bin/false for the shell so they can't SSH in, and add them to group psacln. You'll also need to make sure that the httpdocs directory is 751, not the default 750.

Plesk charges $49.00 to provide a GUI for SpamAssassin configuration. While I didn't save any money doing this myself, maybe you will: here's how to get SpamAssassin going with Plesk's qmail implementation. If you have the Plesk SpamAssassin RPM installed (usually available in /root/swsoft), it provides a spammng command line utility for tweaking the SpamAssassin configuration. This utility appears to work without checking your license information: you can run /etc/init.d/spamassassin stop than spammng -c -C start. This restarts the spamd daemon with the proper command line flags for Plesk's qmail install.

Going a bit further, try spammng -c -C -e --mailname "morbus@disobey.com" start: this will enable SpamAssassin for the specified mailbox by editing the .qmail file in the relevant directory. For my install, this was /var/qmail/mailnames/disobey.com/morbus. With these two bits of information, we can combine Plesk's qmail with the default SpamAssassin installation without spending any cash. I have not yet figured out how to do this server wide (every incoming piece of mail is processed) or domain wide (every mail for a specific domain is processed). You?

In the .qmail file, Plesk writes the following:

| /usr/local/psa/bin/psa-spamc accept
| true
./Maildir/

psa-spamc is a shell wrapper around the SpamAssassin spamc utility and allows one argument: whether to "accept"/deliver mail that is flagged as spam based on the /etc/mail/spamassassin/ configuration, or whether to "reject" it. It'd be nice to have some granularity to say "reject everything over score 10", but eh, not a biggie.

The last thing is to reteach the /etc/init.d/spamassassin startup script. Since we haven't paid Plesk to fiddle with SpamAssassin, we have to teach our default install how to interact with Plesk's qmail without their help. If you've started the spamd daemon from Plesk's spammng, run the following to capture the startup configuration: ps auwx | grep spamd. You'll get something along the lines of:

/usr/bin/spamd --username=popuser --daemonize --nouser-config --helper-home-dir=/var/qmail --max-children 5 --create-prefs --virtual-config-dir=/var/qmail/mailnames/%d/%l/.spamassassin --pidfile=/var/run/spamd/spamd_full.pid --socketpath=/tmp/spamd_full.sock

Open up /etc/sysconfig/spamassassin and make it look like:

SPAMDOPTIONS="-d -c -m5 -H /var/qmail --username=popuser --nouser-config
--virtual-config-dir=/var/qmail/mailnames/%d/%l/.spamassassin --socketpath=/tmp/spamd_full.sock"
SPAMD_PID=/var/run/spamd/spamd_full.pid

SPAMDOPTIONS is one line. Restart spamd with /etc/init.d/spamassassin restart and check Plesk's qmail log at /usr/local/psa/var/log/maillog. If everything goes right, you should be able to send yourself a piece of mail and notice two things: spamd will process each incoming message and report the results and a .spamassassin directory will show up in the right domain and user directory under /var/qmail/mailnames/. Done.

Plesk's licensing is annoying in other ways: I can only use 30 domains within my current install. Thankfully, domain aliases don't count against this limitation and, with Drupal's multisite capabilities, I can run any amount of domains on one code base with multiple databases. Unfortunately, this is a problem when it comes to logfiles and analysis: I'm not entirely sure if Apache's ServerAlias is considered %v for split-logfile. Needs more testing before I can fully implement domain aliases.

Tags: