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.