Apache Logging via ServerAlias

My last problem with Plesk was a side-effect of working around its thirty domain limit using Apache's ServerAlias and Drupal's multisite configuration. By doing so, all log data was being sent to a single file which made it impossible for me to tease out individual domain stats. The standard solution - using an Apache LogFormat with %v preprocessed via split-logfile - didn't work because %v only covered ServerName, not ServerAlias.

I had initial success swapping out %v for %{Host}i, but another problem arose: %{Host}i happily reports subdomains, which split-logfile then cheerful sends to independent logfiles. That may work for some folks, but the www/no-www problem still rears its ugly head. I eventually settled on using SetEnvIf along with CustomLog:

SetEnvIf HOST "^(.*\.)?(disobey|ghostsites)\.com" log_disobey
SetEnvIf HOST "^(.*\.)?(secretsite)\.com" log_secretsite
CustomLog /statistics/logs/ combined env=log_disobey
CustomLog /statistics/logs/ combined env=log_secretsite

Plesk will include extra directives like the above if you stick them in /var/www/vhosts/ and restart Apache. The above approach gives me lots of leeway - here I'm sending all subdomains (or lack thereof) to the same files, and also combining multiple domains into one as needed.

Now it's just a simple matter of adding a new /etc/logrotate.d/ config for these new logs and pointing a log analyzer at 'em (I like Analog because you can shut off all the gay-ass pie charts). Another nice side-effect of the above is we're not touching Plesk's default vhost logs or Webalizer: I'll still be able to see a collected view of all my server names and aliases as before.

Panache and Peril with Plesk

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 "" 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/ 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

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/ --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"

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.


Subscribe to RSS - Plesk