Archive for the ‘Plesk for Linux’ Category

MySQL 5.1.x on Plesk 8.3 and later

Tuesday, August 3rd, 2010

I have upgraded MySQL to version 5.1.48 on a number of CentOS based servers running different versions of Plesk. The versions of Plesk ranged from 8.3.0 all the way to 9.3.0.

IMPORTANT: After the upgrade, run

mysql_upgrade ––user=admin ––password=`cat /etc/psa/.psa.shadow`

to ensure all the required tables for MySQL 5.1.x gets created.

I also recommend running a

mysqlcheck ––optimize ––user=admin ––password=`cat /etc/psa/.psa.shadow` ––all-databases

to optimise all databases for MySQL 5.1.x after the upgrade completes.

It goes without saying, but it is a VERY GOOD IDEA, to backup /var/lib/mysql, before you start with the upgrade process.

Please note that since MySQL 5.0.12, MySQL adheres to the SQL:2003 standard. This may potentially break some SQL statements that appears to be valid SQL statements and that worked perfectly in MySQL 4.x.

Lastly, I picked up one error with one database on one server, so far:

When clients try to access their database via “DB WebAdmin” in the Plesk control panel:

MySQL said: Documentation
Non-static method PMA_Config::isHttps() should not be called statically

The fix is simple and published at the following URLs:

Courier-IMAP 4.x and later with Plesk 8.3

Tuesday, August 3rd, 2010

I have not confirmed this problem in any version other than Plesk 8.3.0, simply because I have not had the time. :(

According to the Parallels forums and documentation, you should be able to upgrade the version of Courier-IMAP running on the server to any later version.

I however attempted to upgrade to Courier-IMAP 4.7.0 and 4.8.0 using authlib 0.6.3 with no success.

Then I read the following entry in the Courier-IMAP Changelog:

2004-11-05 Mr. Sam

* pop3dserver.c (main): Authenticated address is in AUTHENTICATED,
not AUTHADDR, now.

It would appear that this one change, breaks the authpsa authentication module so that one can not implement later versions of Courier-IMAP on Plesk 8.3.0, since authpsa expects the authentication information in the AUTHADDR shell variable.

Courier-IMAP 3.0.8 on CentOS with Plesk

Tuesday, August 3rd, 2010

I ran into a problem where I wanted to recompile Courier-IMAP so that it can work with Plesk 8.3 on my CentOS server.

After a lot of searching to locate which is now a very outdated version of Courier-IMAP, I bumped into a problem during the recompiling of Courier-IMAP.

The error I received was:
In file included from authstaticlistsearch.c:9:
/usr/include/stdio.h:385: error: syntax error before ‘&&’ token

A bit of Googling lead me to a February 2005 post on the atmail website, which I repeat below for ease of reference:

Patching Courier-IMAP for Fedora/Redhat non-RPM in

This article applies to @Mail Server installations only.

Description: The standard Courier-IMAP 3.0.8 distribution will not build on stock Fedora/Redhat systems. Compilation fails while building the authlib library, usually with an error message like:

In file included from authstaticlistsearch.c:9:
/usr/include/stdio.h:385: error: syntax error before ‘&&’ token

A review of the stdio.h file shows that no ‘&&’ symbols appears on or near line 385.

Solution: The courier-imap/authlib directory contains a file named ‘debug.h’ to support the debugging of authentication attempts against the Courier IMAP server. This file contains a C preprocessor macro named ‘dprintf’ that conflicts with the ‘dprintf’ function defined in glibc’s ‘stdio.h’. This conflict isn’t a problem so long as ‘#include ‘ appears before ‘#include “debug.h”‘ in the authlib source files. Unfortunately, this is not the case for files ‘authstaticlistsearch.c’, ‘authmoduser3.c’, ‘mod.h’, ‘authtest.c’, ‘debug.c’, and ‘authdaemon.c’.

To fix this problem, open these files in a text editor and move the ‘#include “debug.h”‘ line so that it is the last include directive. Make sure that you do not paste it into a ‘#if … #endif’ block. Once you have made these changes, the build process should succeed.

webmailmng Strange error

Saturday, January 16th, 2010

After applying hotfix 1 for Plesk 9.2.3, we started experiencing strange problems with webmail, in our case atmail, but it may apply to horde as well, on the server.

A typical example of an error would be:

Unable to get options for atmail webmail

Looking at the files installed by the hotfix, you will notice that the hotfix installs a new copy of:


which is why the problem starts.

There is a BUG in the newer /usr/local/psa/admin/sbin/webmailmng

Instead of trying to access the config files in


the new version now looks for a config file in


My quick workaround is to simply, make /etc/psa-webmail/atmail/ a symbolic link to /etc/psa/webmail/atmail/ which seems to temporarily solve the problem.

The permanent fix is apparently to upgrade to Plesk 9.3.0, which was available at the time of writing.

Strange MySQL error

Wednesday, December 2nd, 2009

While upgrading to Plesk 9.2.3 on one of my non-production servers, the Plesk upgrade process failed with the following error:

MySQL query failed: Got error -1 from storage engine

I was stumped by this error initially, since searching on the Plesk forums and Google, did not really yield any results.

I finally stumbled across a post by Derick Ng on Planet CakePHP, in which the same problem was described. Kudos to the poster for making the information available.

Bottom line is that I used the non-production server to do an InnoDB database recovery and the MySQL server was still setting the InnoDB engine into recovery mode. While the InnoDB engine is in recovery mode, you can not add data to the InnoDB tables.

Check for innodb_force_recovery in your my.cnf

Plesk 9.2.x & tomcat5

Saturday, September 12th, 2009

The startup scripts for tomcat5 on Plesk 9.2.x for Linux is broken on both 32-bit and 64-bit platforms, at very least for CentOS 5.

The fix is trivial.

Set the JAVA_HOME variable in the /etc/tomcat5/tomcat5.conf file as well as the /etc/sysconfig/tomcat5 file.

Apply the following fix to the /usr/bin/dtomcat5 script.

Around line 67 of the file it should read:

if [ -z “$CATALINA_HOME” ]; then

Change the above code, by adding one line, so it reads as follows:

if [ -z “$CATALINA_HOME” ]; then
    . “${TOMCAT_CFG}”

Testing the change can be achieved by running the following command:

tomcat5 version

It should produce output similar to the information below:

Using CATALINA_BASE: /usr/share/tomcat5
Using CATALINA_HOME: /usr/share/tomcat5
Using CATALINA_TMPDIR: /usr/share/tomcat5/temp
Server version: Apache Tomcat/5.5.23
Server built: Jul 27 2009 05:24:08
Server number:
OS Name: Linux
OS Version: 2.6.18-128.7.1.el5
Architecture: amd64
JVM Version: 1.6.0-b09
JVM Vendor: Sun Microsystems Inc.

Strange FrontPageAlias() problem on Plesk ….

Wednesday, December 17th, 2008

The FrontPage hit counter for a site was not working. I kept on getting the following error in the log file of a domain that has FrontPage enabled:

Incorrect permissions on webroot “/var/www/vhosts/” and webroot’s _vti_pvt directory in FrontPageAlias().

Changing to the website’s httpdocs directory and running the command below, fixed the problem.

chgrp psaserv _vti_pvt

Thank you goes to zymsys

PHP 5.2.5 and Plesk 8.1.x and Plesk 8.2.x …

Monday, December 10th, 2007

Oops, the latest version of PHP breaks a few things on Plesk 8.1.x and Plesk 8.2.x installations. It propably affects other installations as well, but I stopped testing since I was only interested in Plesk 8.2.x and later.

According to atomicrocketturtle the problem will be fixed in Plesk 8.3. We will just have to wait and see.

On rackerhacker‘s blog I found a very elegant solution to the problem that was provided by Kevin M.

I repeat the entry from rackerhacker‘s blog:

There’s a few issues with PHP 5.2.5 and the version of Horde that is bundled with Plesk 8.1.x and 8.2.x. The PHP include paths that appear in the Apache configuration generated by Plesk conflict with the PHP installation, and that causes the Horde webmail interface to segmentation fault.

To fix the problem, create a file called /etc/httpd/conf.d/zz050a_horde_php_workaround.conf and put the following inside it:

<DirectoryMatch /usr/share/psa-horde>
php_admin_value include_path "/usr/share/psa-horde/lib:/usr/share/psa-horde:/usr/share/psa-horde/pear:."

Reload the Apache configuration and your Horde installation should work properly with PHP 5.2.5.

Freeing some file descriptors in Plesk 8.2.0 and later …

Monday, December 10th, 2007

Finally, SWSoft has come to the party and added piped logging into the Plesk configuration. This is simply fantastic since it has enabled me to run many more websites on a shared hosting server. Yay!!

To enable piped Apache logs, do the following:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "replace into misc (param,val) values ('apache_pipelog', 'true');"
# /usr/local/psa/admin/sbin/websrvmng -v -a

A big “thank you” goes to Racker Hacker for this piece of information.

Urrgghh …. FrontPage!

Saturday, December 1st, 2007

10 December 2007: I have not been able to get this solution to work at all, even though mod_frontpage is compiled against Apache 2.2.

20 December 2007: I have found enough time to spend hours on debugging the problem and I have successfully been able to get mod_frontpage working on my CentOS 5 server running Plesk 8.2.1 and Apache 2.2. I have updated the article below where needed.

As most of you are aware, Microsoft FrontPage (FP) has long ago reached its end-of-life. Microsoft no longer distributes FrontPage or FrontPage Server Extensions (FPSE). Now, this may be all well enough and most us understand why. The problem unfortunately lies with the user base. Many people still use and rely on the old outdated versions of Microsoft FrontPage.

SWSoft stopped shipping FPSE as of Plesk version 8.1.0. The last version of FPSE that I could locate was in version 8.0.1 of Plesk.

Version 8.0.1 was also never released for CentOS5 or Red Hat Enterprise Linux 5 (RHEL5), which means that there are effectively no RPMs for FPSE, that was compiled against Apache 2.2.x.

This effectively meant that you had to search for an OLD copy of fp50.lin.tar.gz and compile it yourself. Not the most ideal solution.

Enter, crash. crash provided the solution to the problem on SWSoft’s forum. I will be repeating most of crash’s post below.

You will need one of the older SWSoft FPSE RPM’s. I used frontpage-5.0-72psa.centos4.2 and frontpage-5.0-72psa.rhel4. The RPMs are located in the Plesk 8.0.1 .tar.gz file, in the ./opt/fp directory.

You will need to install one of the above RPM’s onto your system.

Once installed, do the following:

cd ~
mkdir frontpage-5.0
cd frontpage-5.0
cp -afr /usr/local/frontage .
cd ..
tar -cvf frontpage-5.0.tgz ./frontpage-5.0/

You should now have a frontpage-5.0.tgz file, that will be used.

crash provided the following patches to have mod_frontpage compile against Apache 2.2.x. (The patches should allow you to compile mod_frontpage against Apache 2.0.x or Apache 2.2.x [There are a few tiny differences])

Download the patches: FrontPage Server Extension Patches for CentOS5 and Apache 2.2.x (The file was updated on 20 December 2007)

You need to have the httpd-devel RPM installed. yum install httpd-devel, will usually be sufficient.

Now do the following:

cd /usr/src/redhat
tar zxvf mod_frontpage-patches.tgz
rpmbuild -bb frontpage.spec

If all goes well, the RPM build process should complete without any errors and you will have a brand new RPM to install FPSE with on CentOS5/RHEL5.

Credit to crash’s post. I discovered a few bugs in the patches originally provided by crash.

A few tips:

  1. If you installed the SWSoft RPM, you need to remove the mod_frontpage entry from the LoadModules section in the /etc/httpd/conf/httpd.conf file. If you do not Apache will complain that mod_frontpage is already loaded when you restart Apache.
  2. I have commented out the last 3 lines from /etc/httpd/conf.d/mod_frontpage.conf. Plesk already caters for this in the httpd.include file in each vhost.
  3. FrontPage Administration Pages only work in Internet Explorer, or at least for me.
  4. The FrontPage Server Extensions are EXTREMELY sensitive to file permissions.

Dr.Web and CentOS5

Saturday, December 1st, 2007

Dr.Web and CentOS5 does not like each other by default.

The version of Dr.Web used in Plesk 8.2.x, is linked against older versions of libstdc++ and openssl.

To get Dr.Web to run on CentOS5, you need to install the some compatibility libraries.

The following should get you sorted:

yum install compat-libstdc++-33.i386 openssl097a.i386

Plesk 8.1.0 – Disabling Virtuozzo Promo

Saturday, February 24th, 2007

SWSoft decided that the wise thing to do is to start advertising their products in the control panel, effectively spamming the clients that pay a lot of money for the licenses.

To disable the promo, edit the language file, located here:


Search for the following string:

virtuozzo__promotion or virtuozzo__promotion_top

SWSoft promised that it will remove the advertising from future versions. Let’s hope they do.

Remember, you may need to edit different files for different languages.

Edit: This also works in versions 8.1.1, 8.2.0 and 8.2.1

Plesk 8.0.1 and pleskbackup

Saturday, August 19th, 2006

Since Plesk 8 for Unix, SW-Soft, changed the backup utility from the old psadump/psarestore utilities available in Plesk 7.5.4 and earlier to the new pleskbackup/pleskrestore utilities.

I have read a lot of posts from unhappy people about the new utilities. I can honestly say that my only complaint is that SW-Soft decided to break compatibility between the pre-Plesk 8.0 and the post-Plesk 8.0 backup utilities.

That being said, the first version of the backup utilities that I tried was for Plesk 8.0.1, with at least one, maybe 2 hotfixes applied.

I have found the new Plesk 8.0.1 backup utilities to be a lot faster and a lot easier to use than their predecessors.

Yes, the backup file is still a gzipped, MIME encoded file but at least the backup utilities now add the filenames to each MIME part, making it possible to extract the backup archive into multiple clearly named files. Then it is a simple untar of the correct part to get your data.

All in all, not too bad.

By default, the new backup utilities will split your backup file into 1GB chunks. You may change this behaviour, by setting the following variable before running the backup:

/usr/local/psa/bin/pleskbackup –all /path/to/file/FILENAMEHERE -verbose

The PLESKX_SPLIT_SIZE variable expects a number of bytes as input. In the above example we set the chunk size to 2GB.

To be able to work with the MIME files, you will need a MIME decoder. You may want to search for mpack or get ripmime.

Running suPHP and mod_php side by side on Plesk

Sunday, May 14th, 2006

By default all the Plesk servers runs mod_php for speed. This has one major drawback and that is that if a clients creates files via PHP, they are owned by the webserver user under which mod_php runs. The solution to the problem seems to enable suPHP for the clients that needs to create files via PHP.

Below is the procedure that I found to work:

  1. Download the mod_php RPM from the Dag Wiers repository:


  2. Install the mod_php RPM:

    rpm -Uvh mod_suphp-0.6.1-2.1.el3.rf.i386.rpm

  3. Disable able the mod_suphp AddHandler in /etc/httpd/conf.d/suphp.conf
  4. Your /etc/httpd/conf.d/suphp.conf, should only have the following lines:

    LoadModule suphp_module modules/
    LoadModule php4_module modules/
    suPHP_Engine off

    Putting the above into your config will default to PHP pages being run by mod_php.

  5. To switch a virtual host over to mod_suphp, use the following:

    <Directory /home/httpd/vhosts/<VHOST>/httpdocs>
    <IfModule sapi_apache2.c>
    <IfModule mod_suphp.c>
        RemoveHandler x-httpd-php
        php_admin_flag engine Off
        suPHP_AddHandler x-httpd-php .php
        suPHP_Engine on
        AddHandler x-httpd-php .php
        suPHP_UserGroup <USER> <GROUP>

    The config above will only activate if both mod_php and mod_suphp is loaded. Remember to replace the <VHOST>, <USER> and <GROUP> entries with the correct virtual host, Unix user and Unix group.

EDIT: In later versions of PHP, the CLI and CGI version are 2 separate binaries. You now need to edit the /etc/suphp.conf file to reflect the correct binary in the x-httpd-php=php:/usr/bin/php-cgi entry. To determine which binary you need to add, simple do a php -v on the command line. The binary that outputs the cgi information as part of the version information, is the correct binary.

RubyGems on RHEL3/CentOs3

Saturday, May 13th, 2006

This howto guide is based on RubyGems version 0.8.11 which was the current version at the time of writing this guide.

Download the mod_RubyGems source code from:

Extract the .tgz file to a suitable location:

cd /usr/src
tar zxvf /usr/local/src/rubygems-0.8.11.tgz
cd rubygems-0.8.11.tgz

Run the setup command:

ruby setup.rb

Now compile the program:


Finally, install ruby:

make install

It is now time to configure Apache to run with mod_ruby. Please see this post.

Howto install mod_ruby on RHEL3/CentOS3

Wednesday, May 10th, 2006

This howto guide is based on mod_ruby version 1.2.5 which was the current version at the time of writing this guide. We also need version 1.2.5, since it supports the Apache::RailsDispatcher, which is needed if we want to run RubyOnRails in our Plesk environment.

Download the mod_ruby source code from:

Extract the .tar.gz file to a suitable location:

cd /usr/src
tar zxvf /usr/local/src/mod_ruby-1.2.5.tar.gz
cd mod_ruby-1.2.5

Run the configure command:

./configure.rb --with-apxs=/usr/sbin/apxs

Now compile the program:


Finally, install ruby:

make install

It is now time to configure Apache to run with mod_ruby.

Apache::RailsDispatcher can run multiple applications in the same process. It works like this:

  • require loads libraries into the top level, and they are shared with all applications.
  • require_dependency loads libraries into an anonymous module for each application.
  • In the development environment, the anonymous module is orphaned on each request. So required_dependency loads libraries every time.
  • In the production environment, the same anonymous module is used for the same application. So required_dependency loads libraries only at once.
  • Rails configurations such as ActiveRecord::Base.colorize_logging are reset on each request.

This hack is just a workaround until YARV supports multiple VM instances. We can get it in the near future, I hope.

To use Apache::RailsDispatcher, you have to write the following configuration in httpd.conf.

RubySafeLevel 0
# If you use RubyGems
# RubyRequire rubygems
RubyRequire apache/rails-dispatcher
RubyTransHandler Apache::RailsDispatcher.instance
<Location /ruby-application-name>
    SetHandler ruby-object
    RubyHandler Apache::RailsDispatcher.instance
    RubyOption rails_uri_root /ruby-application-name
    RubyOption rails_root /path/to/rails/root
    RubyOption rails_env production

Please note that you can’t override exinting classes like this:

class Array     def cycle()         self.each_with_index {|o, i| yield(o, %w(odd even)[i % 2])}     end end

You should prepend Object:: to the class name:

class Object::Array     def cycle()         self.each_with_index {|o, i| yield(o, %w(odd even)[i % 2])}     end end

This behaivour is same as Kernel.load(filename, true). If you don’t like this, please convince Matz to change it.

Your done. You should now have a valid ruby interperter running on your server.

Portions of this post is courtesy of:

Configure Ruby 1.8.4 on RHEL3/CentOS3

Wednesday, May 10th, 2006

This howto guide is based on ruby version 1.8.4 which was the current version at the time of writing this guide.

Download the ruby source code from:

Extract the .tar.gz file to a suitable location:

cd /usr/src
tar zxvf /usr/local/src/ruby-1.8.4.tar.gz

Run the configure command:

./configure --prefix=/usr --sysconfdir=/etc --enable-shared --enable-install-doc

Now compile the program:


Run the test suite:

make test

You should receive a: “test succeeded” output.
Finally, install ruby:

make install

Your done. You should now have a valid ruby interperter running on your server.

Howto: Install mod_python on Plesk

Wednesday, May 10th, 2006

This is a simple guide to install/upgrade mod_python on a Plesk RHEL box, running Apache 2.0.x. You need to have at least Python version 2.2.1 installed for this to work.

I could not get mod_python version 3.2.8 running at the time of writing.

  1. Download and extract mod_python:

    cd /usr/local/src
    tar zxvf mod_python-3.1.4.tgz

  2. Configure & install mod_python

    cd mod_python-3.1.4
    ./configure --with-apxs=/usr/sbin/apxs (check where your apxs is by typing: locate apxs)
    make install

  3. Configure Apache:

    vi /etc/httpd/conf.d/pyhton.conf

    Locate your LoadModule – section and add the following line under the others:

    LoadModule python_module modules/

  4. Installation done, now time for testing:

    First go to a publicly accessible directory. Make a test directory for mod_python by typing:

    mkdir python

    Now open vi and write the following lines:

    AddHandler python-program .py
    PythonHandler testingpython
    PythonDebug O

    save the file as .htaccess.

    Now open up vi again and copy/paste the following lines:

    from mod_python import apache

    def handler(req):
            req.write("Hello World!")
            return apache.OK

    close and save as Those are tabs not spaces. If you left align everything you will get this error:

    IndentationError: expected an indented block (, line 4)"

    Now restart Apache by typing: service httpd restart

Take your browser to and you should see “Hello World!” If you can see this message then you have succesfully installed mod_python.

Dr.Web, qmail & SpamAssassin on Plesk 7.5.4

Wednesday, May 3rd, 2006

For some reason the Dr.Web, qmail and SpamAssassin integration on Plesk sometimes does not work properly after an upgrade.

It is important to make sure that the binaries in the /var/qmail/bin directory have the following permissions, to enable Dr.Web, qmail and SpamAssassin to work together.

-r-s–x–x 1 drweb qmail 161024 Mar 19 01:34 qmail-queue
-r-s–x–x 1 drweb qmail 161024 Mar 19 01:34 qmail-queue.drweb
-r-s–x–x 1 qmailq qmail 15936 Aug 24 2005 qmail-queue.origin

The process runs as follows:

  1. Incoming mail will be delivered using the qmail-queue binary, which is a specially compiled version that allows qmail to scan the email for viruses.
  2. The qmail-queue binary will write a temporary file in the /var/drweb/spool/ directory. It is therefore important to check the permissions on the /var/drweb/spool/. They should be:

    drwxrwx— 2 drweb nofiles 4096 May 3 13:20 spool

  3. The qmail-queue binary will also read the /etc/drweb/drweb_qmail.conf file and it will execute the file found in the QmailQueue = tag, once virus scanning is complete. The QmailQueue = tag usually contains:

  4. After the virus scanning process completes, the qmail-queue.origin binary will run. This binary will in turn run the SpamAssassin rules as defined in each users configuration.

The following files maybe useful in locating a problem:

  1. /usr/local/psa/var/log/maillog – This file contains the mail logs and you will quickly see if any errors are being generated in it.
  2. /var/drweb/log/drwebd.log - This file contains the Dr.Web logs for all scanned emails.

Plesk 7.5.4 Restore

Thursday, April 27th, 2006

Finally I had to do a Plesk restore. I think I may have developed an ulcer trying to prepare for this event, but I have survived it.

I had a full Plesk dump following the backup method mentioned here.

The restore was quite straight forward:
1. I had to create an ip map file. My file contained the following information, since I was restoring Plesk to the same server: -> eth0 : (Only this single line). The file was called: ipmap
2. The restore required a shells map file. My file contained the following information, since I was restoring Plesk to the same server:
/bin/sh => /bin/sh
/usr/local/bin/rbash => /usr/local/bin/rbash
/usr/bin/false => /usr/bin/false
/bin/csh => /bin/csh
/bin/bash => /bin/bash

The file was called: shellsmap

I then ran a test restore, using the following command:
cat <backup_file_base>.* | /usr/local/psa/bin/psarestore -t --force --restore-admin --restore-server -m ipmap -s shellsmap -f -

Finally I ran a full restore, using the following command:
cat <backup_file_base>.* | /usr/local/psa/bin/psarestore --force --restore-admin --restore-server -m ipmap -s
shellsmap -f -

During the restore I had a large number of errors, about:

sh: – : invalid option
Usage: sh [GNU long option] [option] …
sh [GNU long option] [option] script-file …

It would however appear as if these errors had very little impact on the over all restore.

The biggest problem I had after the restore was that no FTP account was working any more. Luckily I wrote a little script to extract the FTP usernames and passwords from the database and then used the information to reset the password on the system account. This fixed the problem.