Plesk 9.x overuse policy (and how to avoid domains being suspended)
Parallels, in their infinite wisdom, introduced new "overuse" policies into their Plesk control panel as of version 9.0. A great idea when just starting out, but a nightmare when upgrading from a previous version, since it changes the default behavior when clients and domain owners reach their pre-assigned limits. Now, instead of just warning that you're over a limit, it SUSPENDS the account and domain. What a great idea, how useful! Clients *love* that!
So how do you undo this when you have new accounts being added, and existing accounts that don't allow for this type of "overuse" setup, and are suspending clients and domains when they use 1KB more disk space or 1KB more bandwidth than they are supposed to?
New accounts can take advantage of the new "overuse policy" settings within the templates, but existing clients are going to have a tougher time, you'll have to update their policy in a template, then apply the new template, or you can use the CLI utilities and change the overuse policy per client, which is what I opted for here.
Using the Plesk CLI utilities (here running on CentOS 5.x):
replace "clientuser" with your client login name you wish to update
check client preferences for their overuse policy:
/usr/local/psa/bin/client_pref.sh --info clientuser |grep Overuse
Overuse policy: block
- For checking all clients on the system (produces a lot of random output):
for i in `cat /etc/passwd |grep "/var/www/vhosts" | awk -F":" '{print $1}'`; do echo -n "$i -- "; /usr/local/psa/bin/client_pref --info $i |grep Overuse; echo ""; done
update overuse policy to "notify" rather than "block":
/usr/local/psa/bin/client_pref.sh --update clientuser -overuse notify
- updating all your clients at once:
for i in `cat /etc/passwd |grep "/var/www/vhosts" | awk -F":" '{print $1}'`; do echo -n "$i -- "; /usr/local/psa/bin/client_pref --update $i -overuse notify ; echo ""; done
check if it was updated:
/usr/local/psa/bin/client_pref.sh --info clientuser |grep overuse
Overuse policy: notify
No longer need to worry about client accounts and domains being suspended due to being over their limits by mere kb! Will need to keep an eye on their use though, and watch overuse emails, since this does mean users could abuse the "limits" that have been set for them now.
Now on to the domains!
Once you're done with fixing up the client accounts, you will have to double check all those domains if you don't want them being suspended.
The following is for editing ALL domains on the Plesk system, you can just run the domain_pref script on a single domain at a time if you prefer.
check domain preferences for their overuse policy:
for i in `ls -1 /var/named/run-root/var/ | egrep -v '(in-addr.arpa|localhost.rev|saved_by_psa|named.root|make-localhost)'`; do echo -n "$i : "; /usr/local/psa/bin/domain_pref --info $i |grep Overuse; done
update overuse policy to "notify" rather than "block" on all domains:
for i in `ls -1 /var/named/run-root/var/ | egrep -v '(in-addr.arpa|localhost.rev|saved_by_psa|named.root|make-localhost)'`; do echo -n "$i : "; /usr/local/psa/bin/domain_pref --update $i -overuse notify ; done
Background:
Fairly unresolved discussion of this issue here: http://forum.parallels.com/showthread.php?t=85216
From the Plesk documentation
Overuse policy. Specify what should be done to the site when disk space and traffic limits are exceeded: To block the site, select the Overuse is not allowed option. To allow the site to operate, select the Overuse is allowed option. Select the check box Notify the domain owner about reaching the resource limits: When the specified resource usage limits are reached, Parallels Plesk Panel will send a notice to the appropriate client account's e-mail address (by default) or to the domain administrator's account, if that is specified at Home > Notifications (in the Logs & Statistics group) > Resource usage limits exceeded by domain option.Note: The overuse policy does not apply to the limits set on size of mailboxes (mailbox quota). Therefore, even if you enable overuse, be sure to allocate enough disk space to mailboxes.
From the administrators guide:
Overuse policy. Specify what should be done when disk space and monthly bandwidth (traffic) allotments are exceeded. We recommend setting this option to Overuse is allowed. Otherwise, the user account and user's sites will be blocked when the resource limits are exceeded.
FreeBSD Plesk 8 – installing php5 as CGI alongside php4
If you have ever needed php5 to run along side php4, you can always compile php5 as a CGI, and let php4 remain as an apache module.
Here we've compiled php5 from FreeBSD's ports, and have installed it as a CGI so that specific vhosts will run on this new php5. The installation was done on a Plesk 8 box running FreeBSD 6.x.
Compiling PHP5 (installation from FreeBSD Ports)
1) Update port tree using portsnap (use `portsnap extract` instead of update if this is the first time you've used portsnap). Or use classic rsync techniques.
portsnap fetch; portsnap update
2) Configure php5 and install:
cd /usr/ports/lang/php5
make config; make install
In the config, the basics should already be selected, make sure you have not selected php5 as an apache module, and keep debugging turned off unless you require this.
3) Compile the php5 extensions.
cd /usr/ports/lang/php5-extensions
make config; make install
In the config, make sure you have selected the extensions that you require. For my purposes, I've selected: BZ2, CTYPE, CURL, DOM, EXIF, FILTER, GD, GETTEXT, HASH, ICONV, IMAP, JSON, MCRYPT, MHASH,MYSQL, NCURSES, PCRE, PDO, PDO_SQLITE, POSIX, SESSION, SIMPLEXML, SOAP, SPL, SQLITE, TOKENIZER, XML, XMLREADER, XMLRPC, XMLWRITER, XSL, ZLIB.
4) Create the directory for your installation of php, and make sure it is owned by the proper user (the siteowner) so that suexec will be happy running binaries in this directory:
mkdir /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi
chown siteowner:psacln /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi
5) Copy the new php-cgi over to this directory (we're naming the php-cgi binary 'php') and make sure to set the ownership to the siteowner, so that suexec can run this binary.
cp /usr/local/bin/php-cgi /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi/php
chown siteowner:psacln /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi/php
6) Move the recommended configuration file to the real configuration file location, edit if necessary:
mv /usr/local/etc/php.ini-recommended /usr/local/etc/php.ini
Now we add the vhost configuration and apache bits:
Add the following to your /usr/local/psa/home/vhosts/yoursite.com/conf/vhost.conf (change "yoursite.com" to your domain name or host)
ScriptAlias /php5-cgi /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi
Action application/x-httpd-php5-custom "/php5-cgi/php"
AddType application/x-httpd-php5-custom .php
AddType application/x-httpd-php5-custom .php5
Run the reconfiguration utility and restart apache:
/usr/local/psa/admin/sbin/my_apci_rst
/usr/local/psa/rc.d/httpd restart
Test out the page with a phpinfo.php script, you can create one easily from the command line, go into the httpdocs directory and run this:
echo "<?php
phpinfo();
?> " > phpinfo.php
From a browser, go to yoursite.com/phpinfo.php and see if you have the new php you just installed showing up. If you do, you have succeeded. If not, or if there are any errors, here are a few things to try:
Troubleshooting
Check the local site error_log:
/usr/local/psa/home/vhosts/yoursite.com/statistics/logs/error_log
Check the suexec log:
/usr/local/psa/apache/logs/suexec_log
Try running php from the command line:
/usr/local/bin/php -v
If you see any errors on the command line, this will result in the binary not working from Apache.
One error I ran into was this:
/usr/local/bin/php --version
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/xsl.so' - Shared object "libgpg-error.so.3" not found, required by "libexslt.so.8" in Unknown on line 0
PHP 5.2.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 26 2007 03:33:26)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
This was caused by some ports being older versions. To solve this, you must make sure that the libgpg-error and related ports are up to date, and then recompile the php5-xsl port:
recompile (from packages -P) libgpg-error and related ports:
portupgrade -rf libgpg-error-\* -P
Recompile xsl related ports, I may be recompiling too many, but this worked for me:
cd /usr/ports/textproc/libxslt
make clean; make deinstall; make install
cd /usr/ports/textproc/php5-xsl
make clean; make deinstall; make install
cd /usr/ports/textproc/php5-xml
make clean; make deinstall; make install
This solved the shared library problem, and allowed php5 to work. You shouldn't have to recompile php after this, since this only impacts the shared libraries.
Double check your /usr/local/etc/php/extensions.ini to make sure that you have all the libraries installed that you require.
Updating Spamassassin on FreeBSD and Plesk
Updating Spamassassin on Plesk and FreeBSD is quite simple without breaking things since the Spamassassin on Plesk is pretty standard.
System: FreeBSD 6.x
Plesk Version: 8.0.x
May work with other versions.
The stock plesk Spamassassin is a 3.1.x variant, which gets pretty old pretty quick. You can upgrade this via the ports by passing a few variables to 'make install' to make sure that you
1) Back up /usr/psa/spamassassin so you have a backup in case something goes wrong:
tar -czf /usr/psa/spamassassin-backup.tar.gz /usr/psa/spamassassin
2) Install the new spamassassin from ports. Please check the prefix, and rules directories to make sure these are good. You can check these by grepping for RULES_DIR on the original plesk /usr/psa/spamassassin/bin/spamassassin file, that will tell you what directories you will want to use.
cd /usr/ports/mail/p5-SpamAssassin
All one line:
make install PREFIX=/usr/local/psa/spamassassin DEF_RULES_DIR=/usr/local/psa/spamassassin/share/spamassassin LOCAL_RULES_DIR=/usr/local/psa/spamassassin/etc/mail/spamassassin
Make sure you run spamassassin --lint to make sure that the rules you have installed are all error free.
/usr/local/psa/spamassassin/bin/spamassassin --lint
Restart spamassassin using:
/usr/local/psa/rc.d/psa-spamassassin restart
It should come back online and work, check the logs to make sure that it has. Send a few emails to make sure your new spamassassin is processing correctly, if so, sit back and enjoy another small plesk victory.
Installing xcache on Plesk 8 on FreeBSD
Installing xcache on Plesk can be a bit of an adventure, especially on FreeBSD, since Plesk doesn't include a lot of the php sources you may require to get this done.
Download xcache 1.2.1 and php-4.4.4 (or whatever version matches what you require, you can check this by running a phpinfo.php script on the webserver)
A way around this is to download the version of php you require (in this case, php-4.4.4, which matches that running on Plesk 8.0.1 on FreeBSD). Once you've got this, you should configure and make php, then install the build environment:
cd php-4.4.4
./configure
make
make install-build
make install-headers
Allow the scripts inside the /scripts directory to be executed:
chmod +x scripts/*
Now you have a build environment for php ready to go, and you can start to compile xcache. Here we use the php-4.4.4 directory to run our php-config from. Then we copy the modules to the php modules directory for Plesk.
cd xcache-1.2.1
./configure --enable-xcache --enable-xcache-optimizer --with-php-config=../php-4.4.4/scripts/php-config
make
cp modules/xcache.* /usr/local/psa/apache/libexec/php/
Edit your php.ini to be similar to the following. This is set up for a dual CPU system, and is set to use 96 megs of cache, which might be a bit too high for low-traffic servers.
Change the YOUR_USERNAME_HERE area to include your username you would like to use for the admin, and YOUR_MD5_PASS_HERE to be an md5 hash of the password you would like to use. You can get the MD5 password hash by doing the following:
md5 -s somepassword
[xcache-common]
;; install as zend extension (recommended), normally "$extension_dir/xcache.so"
zend_extension = /usr/local/psa/apache/libexec/php/xcache.so
[xcache.admin]
xcache.admin.auth = On
xcache.admin.user = "YOUR_USERNAME_HERE"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = "YOUR_MD5_PASS_HERE"
[xcache]
; ini only settings, all the values here is default unless explained
; select low level shm/allocator scheme implemenation
xcache.shm_scheme = "mmap"
; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size = 96M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count = 2
; just a hash hints, you can always store count(items) > slots
xcache.slots = 8K
; ttl of the cache item, 0=forever
xcache.ttl = 86400
; interval of gc scanning expired items, 0=no scan, other values is in seconds
xcache.gc_interval = 3600
; same as aboves but for variable cache
xcache.var_size = 8M
xcache.var_count = 2
xcache.var_slots = 8K
; default ttl
xcache.var_ttl = 3600
xcache.var_maxttl = 86400
xcache.var_gc_interval = 300
xcache.test = Off
; N/A for /dev/zero
xcache.readonly_protection = Off
; for *nix, xcache.mmap_path is a file path, not directory.
; Use something like "/tmp/xcache" if you want to turn on ReadonlyProtection
; 2 group of php won't share the same /tmp/xcache
; for win32, xcache.mmap_path=anonymous map name, not file path
xcache.mmap_path = "/dev/zero"
; leave it blank(disabled) or "/tmp/phpcore/"
; make sure it's writable by php (without checking open_basedir)
xcache.coredump_directory = "/tmp/"
; per request settings
xcache.cacher = On
xcache.stat = On
xcache.optimizer = On
[xcache.coverager]
; per request settings
; enable coverage data collecting for xcache.coveragedump_directory and xcache_coverager_start/stop/get/clean() functions (will hurt executing performance
xcache.coverager = Off
; ini only settings
; make sure it's readable (care open_basedir) by coverage viewer script
; requires xcache.coverager=On
xcache.coveragedump_directory = ""
Now you need to copy the admin files to some location on your server :
cp -R admin ~someuser/httpdocs/xcache_admin
cd ~someuser/httpdocs/xcache_admin/
chown someuser:psaserv *
cp config.php.example config.php
Edit the config.php if you want to use alternate login methods.
You can now restart Apache and you should be able to monitor xcache details from your new xcache_admin location using the login and password you set in php.ini.
Some notes:
* I've set var_size to 8M, but it doesn't seem to ever matter, it never allocates any variables. I'm not sure what the deal with that is.
* I've tried to set xcache_count to 1 or 2, 2 seems to be good on a dual CPU machine, although there have been reports that it crashes or doesn't run as fast. I'm not sure. Perhaps if you have a single CPU machine and try to set that to 2, you might end up in tears.
* The ttl settings are not well tested since this install is quite young. However it seems to work quite well so far.