Scheduled backups failing in Plesk 9.5

October 27th, 2012

If you are using MySQL 5.5 with Parallels Plesk 9.5 then you might have noticed that scheduled backups using the built in backup utility have stopped working.

Backups manually initiated through the Parallels Plesk control panel interface run normally, but they don’t run automatically on the configured schedule. This is thanks to some compatibility issues between the Parallels “backupmng” tool and MySQL 5.5.

A quick fix for this is to adjust the “backup_day” column of the “BackupsScheduled” table in the “psa” database to change the type from “int(10) unsigned” to “int(11)” with the following SQL statement:

ALTER TABLE BackupsScheduled MODIFY COLUMN backup_day INTEGER;

Once this query has been run, you should be able to set up the scheduled backups as normal through the Parallels Plesk interface and they will run without problems or requiring manual intervention.

Blank login page with Parallels Plesk

October 18th, 2012

A recent micro-update from Parallels seems to have broken the login page on some Parallels Plesk servers. In my case, it was a Plesk 9.5.4 server running on Linux.

If you look in the Plesk web server (“sw-cp-server”) error log at “/var/log/sw-cp-server/error_log” then you should see entries such as:

(mod_fastcgi.c.2582) FastCGI-stderr: PHP Fatal error: Call to undefined function get_failure_redirect_url() in /usr/local/psa/admin/auto_prepend/auth.php3 on line 175

The simple fix for me was to re-install the Plesk micro-updates using the autoinstaller command:

/usr/local/psa/admin/sbin/autoinstaller –reinstall-patch

Once this has finished, your Parallels Plesk login page should be working as normal again!

Parallels Plesk Atmail and Error: Password file could not be found

May 21st, 2012

When logging into the Atmail webmail interface used by Parallels Plesk, you might receive the following error:

Error: Password file could not be found

If you take a look in the log files for the Atmail vhost (/var/log/atmail/error_log) then you should see something along the lines of:

PHP Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/etc/psa-webmail/atmail/.atmail.shadow) is not within the allowed path(s): (/var/www/atmail:/var/log/atmail:/etc/psa:/tmp:/var/tmp) in /var/www/atmail/libs/Atmail/Config.php on line 6

Basically the /etc/psa-webmail/atmail/ folder isn’t on the list of directories that PHP has been told to allow and access to (the open_basedir restriction) and so when Atmail tries to open it’s shadow password file from /etc/psa-webmail/atmail/.atmail.shadow then PHP blocks the request.

The restriction itself comes from the four “php_admin_value open_basedir” lines in the /etc/httpd/conf.d/zzz_atmail_vhost.conf Apache config file, which is in turn generated from the /etc/psa-webmail/atmail/atmail_vhost.conf template.

To fix this, simply open up the /etc/psa-webmail/atmail/atmail_vhost.conf template and change the four lines that look like:

php_admin_value open_basedir “/var/www/atmail:/var/log/atmail:/etc/psa:/tmp:/var/tmp”

to be:

php_admin_value open_basedir “/var/www/atmail:/var/log/atmail:/etc/psa:/tmp:/var/tmp:/etc/psa-webmail/atmail”

Once that’s done, all you need to do is regenerate the Atmail webmail config file from the template and reload the Apache configuration with the following commands:

/usr/local/psa/admin/bin/webmailmng –disable –name=atmail
/usr/local/psa/admin/bin/webmailmng –enable –name=atmail
/sbin/service httpd reload

4GB of RAM on a Juniper J-Series router (J6350)

May 2nd, 2012

Officially the Juniper J-series routers such as the J6350 only supports a maximum 2GB of RAM. The J6350 comes with 1GB of RAM installed and if you want to add more then you have to buy your RAM from Juniper at inflated prices, however as the J-series are standard x86 machines with Netburst era Celeron and Pentium 4 processors you can simply install standard DDR400 RAM if you aren’t worried about being covered by JTAC support.

Not only does installing your own RAM save you a shedload of money compared to the Juniper equivalent part (JXX50-MEM-512M-S), but you can also exceed the “supported” 2GB maximum 4x512MB configuration, which provides additional memory to the control plane. The four memory slots present on a J6350 can take a 1GB DIMM each, however thanks to a 32bit architecture and mapping of the PCI bus into the same address space, you can only actually use 3.5GB of that 4GB.

The J-series routers are picky about what RAM they use however, so I like to stick to Crucial sticks; partly as that’s what Juniper use but mostly because I use Crucial elsewhere for their great customer service and a genuinely quality product. If you want to stick with a 2GB maximum then you can use Crucial part number CT2KIT6464Z40B, which provides 2x512MB sticks. Alternatively, Crucial part number CT2KIT12864Z40B provides 2x1GB sticks, allowing you to max the chassis out at 4GB across all four slots.

Once you’ve got all 4GB of memory installed in the chasis, boot the router up and from the JUNOS operational mode CLI issue the command “show chassis routing-engine” – you should see a total of 3584MB of memory split between 3008MB of control plane memory and 576MB of data plane memory. If you only opted for 2GB of memory then the 2048MB total will be split between 1472MB of control plane memory and 576MB of data plane memory.

Remember, you replace the RAM in your routers at your own risk and doing so will likely void your warranty as well as rending your system unspported by JTAC.

SolusVM Nginx PHP bug

February 20th, 2012

It looks like there is a bug in the SolusVM Nginx installer which means that the php_cgi service doesn’t start on a reboot.

It seems that the installer sets the unused “spwan-fcgi” process to start, but not the “php_cgi” service that is actually used to handle SolusVM.

Luckily, this is easy enough to fix by running two commands on any of the master and slave servers which have Nginx installed:

chkconfig –add php_cgi
chkconfig php_cgi on

Missing Parallels Plesk for Linux updates

February 11th, 2012

If you’re using Parallels Plesk 9.x with Postfix as the MTA, there appears to be a bug which can stop Plesk from displaying important updates that are available, including the micro-updates which provide important bug fixes and security updates.

If you are using the Updates section of the Plesk web interface, then no error message is displayed, so it just looks like there are no updates available. However, you can also check for updates using the Parallels autoinstaller utility from the command line:

/usr/local/psa/admin/sbin/autoinstaller –check-updates

After downloading all of the .inf3 files from Parallels, this will give you a badly translated error message:

Unable to process patch config: PSA_9.5.4/plesk-patches-9.5.4-cos5-x86_64.inf3: Failed to parse the patch file at (line 34 column 13)
Group named ‘qmail’ is not exists on this system.

Despite the qmail MTA not being installed because the Postifx MTA is being used, the Plesk autoinstaller utility (which is also used by the web interface) seems to be checking for a “qmail” group. The fix for this is incredibly simple – just create an empty ‘qmail” group:

/usr/sbin/groupadd qmail

Now if you refresh the Updates section in the Plesk web interface or re-run the Parallels autoinstaller from the command line then you should now see the available updates, which you can install in the normal manner.

Regenerate statistics in Parallels Plesk for Linux

February 6th, 2012

Every night Parallels Plesk for Linux servers run a cron job to process various log files and generate statistics. This includes generating the HTML for the AWStats or Webalizer log analysis packages used for the Plesk “web statistics” features as well as updating the disk usage and bandwidth usage for each domain.

Sometimes you need to re-run this task, such as if it failed or if you need to process a particular domain name again. One common reason for this is to correct the disk and/or bandwidth usage figures for a domain.

You can either regenerate the statistics for all domain names (the equivalent of the daily cron job) using:

/usr/local/psa/admin/sbin/statistics –calculate-all

Or you can re-generate the statistics for a single domain name (“example.com” in this case) using:

/usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=example.com

There is a similar tool in Parallels Plesk for Windows under C:\Program Files (x86)\Parallels\Plesk\admin\bin\statistics.exe, however this requires different arguments.

Commercial SSL certificates with SolusVM

February 6th, 2012

When you install SolusVM it generates a self signed SSL certificate for use with the end user control panel and admin interface, however it would be wise to purchase a certificate from a commercial certificate authority to prevent man in the middle attacks (and get rid of annoying browser warning messages).

There are two different methods of installing SSL certificates in SoluSVM depending on if you are using the original Lighttpd web-server or the new Nginx option.

For Lighttpd, you need to place the Base64 encoded DER form of both the private key and the x509 certificate in /usr/local/solusvm/ssl/solusvm.pem and then restart the Lighttpd web-server.

You may need to edit /etc/lighttpd/lighttpd.conf and set “ssl.ca-file” to be the path to the Base64 encoded DER form of the x509 certificate intermediate certificate for your Certificate Authority.

For Nginx, you place the Base64 encoded DER form of both the private key in /usr/local/solusvm/ssl/nginxcert.key and the Base64 encoded DER form of x509 certificate in /usr/local/solusvm/ssl/nginxcert.pem then restart the Nginx web-server.

If you need to include an intermediate certificate for your Certificate Authority, then this also goes in the /usr/local/solusvm/ssl/nginxcert.pem file in Base64 encoded DER form.

Disabling highlighting of objects in Zimbra web UI

February 5th, 2012

Zimbra has a couple of Zimlets (plugins) that highlight parts of messages when viewed in the Zimbra Web Console such as dates, phone numbers and e-mails and turn them into special contextual links. Whilst this functionality is often quite useful, sometimes you just need to see the raw, unadulterated e-mail without your client interfering with the content – particularly if you are testing e-mail designs!

You can either disable Zimlets server wide through the admin console, or on a per-account basis using the preferences. In particular, look for the “Date”, “Email”, “Phone” and “URL Links” Zimlets as these are the four of the default Zimlets in Zimbra 7.x that are responsible for highlighting parts of messages and turning them into contextual links.

Convert SolusVM from Lighttpd to Nginx

February 4th, 2012

Historically the brilliant SolusVM VPS control panel have used the Lighttpd web server on their master and slave nodes, however it is now possible to use the popular Nginx as an alternative web-server.

I’m a big fan of the performance and flexibly of Nginx, not to mention that in my opinion the Nginx configuration files are just much easier to write and maintain than Lighttpd.

Thanks to a nice, easy to use installation script, the process of converting the SolusVM master server/node from Lighttpd to Nginx, just requires running the following commands:

wget http://files.soluslabs.com/solusvm/nginx/nginx-master-el5-x86_64
chmod 755 nginx-master-el5-x86_64
./nginx-master-el5-x86_64

And to convert each of your SolusVM slave servers/nodes from Lighttpd to Nginx, it’s just as simple:

wget http://files.soluslabs.com/solusvm/nginx/nginx-slave-el5-x86_64
chmod 755 nginx-slave-el5-x86_64
./nginx-slave-el5-x86_64

Both of these examples assume that you are running your SolusVM master and slave servers/nodes on a 64-bit CentOS 5.x system, however if you are using CentOS 6.x then just substitute “el6″ for “el5″ in each of these commands.

As part of the installation process, a new self signed SSL certificate will be generated for Nginx, leaving the original SSL certificate used by Lighttpd in it’s place in case you need to roll back for any reason. The roll back is simply a case of stopping and disabling the Nginx and Spawn-FCGI services before re-enabling and starting the Lighttpd service:

chkconfig nginx off
chkconfig spawn-fcgi off
chkconfig lighttpd on
service nginx stop
service lighttpd start