[root@srv~]# /etc/init.d/psa start

Starting xinetd service…               done

Starting named service…             done

Starting mysqld service…           done

Plesk: Starting Mail Server… already started

Starting mail handlers tmpfs storage

Starting Plesk…                       failed

There won’t be an obvious error message in any log file location (/var/log/*, /usr/local/psa/var/log/*, /usr/local/psa/admin/logs/*), but it will most likely be caused by your recent openssl upgrade. Solution is this.

Edit April 2nd: There’s now a Knowledge Base article available by Parallels on this issue: “Latest update of openssl breaks Parallels panel“. You might want to read that too, same solutions as stated below.

Edit April 2nd²: Parallels has release an official solution, using a Plesk update: http://kb.parallels.com/en/8338

1) Downgrade method

[root@srv~]# yum downgrade openssl openssl-devel

2) Using RPM packages

You have to download these first! After completing the next steps, you’ll be without openssl – and downloading through wget or curl won’t  work because of missing libraries. Please take note: the following is at your own risk (and if you lose your SSH connection in the meanwhile, you’re screwed).

Find your current OpenSSL version, it should read version “el5_4.6″.

[root@srv~]# rpm -qa | grep -i openssl
openssl-0.9.8e-12.el5_4.6

Remove the package (if you haven’t downloaded the openssl package yet, do so first !!). (due to the font of this blog, it’s confusing, but the parameter = ‘ – - nodeps’).

[root@srv ~]# rpm -e –nodeps openssl-0.9.8e-12.el5_4.6

And re-install the correct version (replace the RPM with the one for your achitecture).

[root@srv  ~]# rpm -ivh openssl-0.9.8e-12.el5_4.1.x86_64.rpm
warning: openssl-0.9.8e-12.el5_4.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID e8562897
Preparing…                ########################################### [100%]
1:openssl                ########################################### [100%]

Afterwards, you’ll be able to start Plesk again.

[root@srv~]# /etc/init.d/psa start

Starting xinetd service…               done

Starting named service…             done

Starting mysqld service…           done

Plesk: Starting Mail Server… already started

Starting mail handlers tmpfs storage

Starting Plesk…                       done

For now the only workaround is to downgrade openssl, either with yum or with rpm (if yum is not configured):

# wget -c http://mirrors.kernel.org/centos/5/updates/x86_64/RPMS/{openssl-0.9.8e-12.el5_4.1.x86_64.rpm,mod_ssl-2.2.3-31.el5.centos.2.x86_64.rpm,httpd-2.2.3-31.el5.centos.2.x86_64.rpm}

# rpm -Uvh –oldpackage {openssl-0.9.8e-12.el5_4.1.x86_64.rpm,mod_ssl-2.2.3-31.el5.centos.2.x86_64.rpm,httpd-2.2.3-31.el5.centos.2.x86_64.rpm}

# /etc/init.d/sw-cp-server start

Update Host’s IP address in Plesk
update psa.ip_addresses set ip_address = ‘<new-ip-address>’ where ip_address=’<old-ip-address>’

Changing DNS records for all hosts:
update psa.dns_recs set host = ‘<new-ip-address>’ where host = ‘<old-ip-address>’;
update psa.dns_recs set displayHost = ‘<new-ip-address>’ where displayHost = ‘<old-ip-address>’;
update psa.dns_recs set val = ‘<new-ip-address>’ where val = ‘<old-ip-address>’;
update psa.dns_recs set displayVal = ‘<new-ip-address>’ where displayVal = ‘<old-ip-address>’;

Then run the following command:
websrvmng.exe --reconfigure-all

This will rebuild all Plesk-generated configs (in this case, for Apache) according to what’s known within Plesk. This way, you can fairly quickly change the main IP address of a server, without a lot of hassle. However, this does not update the DNS config files.

The following should, in theory, also be possible:
websrvmng.exe --change-ip-address --new-ip-address=<new-ip-address> --old-ip-address=<old-ip-address>

Next, you have to start the command that rebuilds the DNS config, based on what’s known within Plesk (as the websrvmng.exe does not update DNS records). The downside: the command needs to be entered for each domain in Plesk, so here’s a script to make this slightly easier:

<?php
	$conn = mysql_connect("localhost:8306", "admin", "<plesk-pass>") or die (mysql_error());
	$dbconn = mysql_select_db("psa", $conn) or die (mysql_error());
 
	$sql = "SELECT * FROM domains AS d";
	$result = mysql_query($sql) or die (mysql_error());
 
	$output = "";
	$newline = "\n";
	while ($row = mysql_fetch_object($result)) {
		$output .= "DNSMng.exe update ". $row->name . $newline;
	}
 
	echo $output;
?>

This will generate all the commands, so you can copy paste them to a “execute.bat” file, and save that in the Plesk/Admin/Bin folder, so it can now execute the DNSMng.exe executable for each and every domain.

When browsing to your Plesk Controlpanel on port 8443, the top bar will load, but the login form won’t be visible. That’s because in the background, it attempts to load that form through a TCP communication started on port 11444.

For everyone behind a firewall, this means changing it so port 11444 TCP incoming is opened up as well.

This change was needed for the Single Sign-On feature in Plesk, which operates on port 11444. If you want quick access to your Plesk again, without changing firewall configs, you can disable Single Sign-On through the following command:

/usr/local/psa/bin/sso --disable

If you don’t want to disable it, you need to open the port.

The cause of this error, is the enabled option to check for DNS blacklists. It’ll find that the user’s (often dynamic) IP address isn’t allowed to send e-mail to the Plesk’s SMTP service. A common cause for this, is the use of the “zen.spamhaus.org“, which is a combination of SBL, XBL and PBL blacklists.

And the PBL blacklist, has the following warning-message in the FAQ.

Caution: Because the PBL lists normal customer IP space, do not use PBL on smarthosts or SMTP AUTH outbound servers for your own customers (or you risk blocking your own customers if their dynamic IPs are in the PBL). Do not use PBL in filters that do any ‘deep parsing’ of Received headers, or for other than checking IP addresses that hand off to your mailservers.

Disabling the zen.spamhaus.org will cure this issue. You can enable the xbl.spamhaus.org;sbl.spamhaus.org DNS blackhole list to get a combination of XBL and SBL blacklists, without PBL.

This does, however, have another drawback. Enabling the remaining DNS blackhole lists, will prevent (authenticated) e-mail communication over port 25. Meaning you still can’t send e-mail.

Bummer. But fixeable.

Enable the Message Submission option, on the Plesk page Server > Mail.

This will make the SMTP service also available on port 587, configured to allow Authenticated SMTP connections with disregard of the DNS Blackhole list. The only drawback is it can’t be used in combination with the zen.spamhaus.org (which is why we changed it in the first place).

Outlook should then be configured to send e-mail over port 587, instead of the default port 25.

Go to Tools > Account Options and doubleclick the account you’re using. Go to More Settings and proceed to the tab “Advanced“. There, you can change the Outgoing mailserver (SMTP) port to 587.

Seems like a lot of work, but it appears to be the only way to use the SMTP service in Plesk, in combination with a DNS Blackhole list and dynamic IP ranges.

You can safely upgrade your MailEnable installation to the version you need, as described on the Knowledge Base of Plesk.

You could also copy the measp.dll file from another installation, and register it using the following command.

Regsvr32 “C:\Program Files\Mail Enable\Bin\MEASP.DLL”

The following registry key should also be added.

Root: HKEY_LOCAL_MACHINE\SOFTWARE\Mail Enable\Mail Enable\Connectors\SMTP
Name: Bad Mail Notification Sender Address
Type: String (REGSZ)
Typical Value: admin@mydomain.com

More information can be found on the MailEnable Knowledge Base: Error ‘ASP 0177 : 800401f3′ when accessing the MEMail COM component.

Unable to create system user: Empty error message from utility.

Here’s the fix.

In the log file “/usr/local/psa/admin/logs/httpsd_error_log” you’ll see the following entry: /usr/share/cracklib/pw_dict: error reading header.

This can be fixed by doing:

rpm -e cracklib-dicts –nodeps
yum install cracklib-dicts

Short solution: stop the DNS service, and then restart the Plesk DNS.

You can test this, by doing the following. Log in via a Remote Desktop connection to your server, and shut down the Plesk DNS service (using the system-tray icon, in the bottom right).

Stop the Plesk DNS Service

 Select the DNS service, and stop it using the button on the right. Now run the following command through a command prompt (start > run > cmd) to see if another service is still listening on the DNS (53) port.

netstat -an | find “53″

Netstat DNS Port Listening

The term “LISTENING” means there’s a service active, that is accepting requests on port 53. Since you shut down the Plesk DNS service, something else is using this port. Go the service management in Windows Server (start > run > services.msc), and find the Microsoft DNS Service.

Microsoft DNS Service Enabled/Started

In the list, the DNS Server will probably be started. Right-click it, and choose “Stop”. If this service is not started, another piece of DNS software is running on your server that’s using up the DNS port. You can check the processlist/task manager to find out which one (popular ones are Bind or Named).

Now run the same command as above, to see if another service is still listening on port 53.

Netstat - No Open DNS Port

Port 53 no longer shows a “LISTENING” status, which means any service running on port 53 is now closed.

Re-open the Plesk Service Monitor, as shown in screen #1, and start the Plesk DNS Service again. Now everything should be fine again.

You see this page because there is no Web site at this address.

1) Did you rename/overwrite the index.html file in the public directory (httpdocs)? This is the page Plesk shows by default.

2) If you did, and are sure the website is uploaded properly, you can try to disable the domain, and re-enable it. After this, site-preview might work again.

3) If you see a 404 error – page not found, you can try to edit the config-file, as described here.

There are problably a bunch of other possibilities, and reasons, why the Site Preview doesn’t work. If you have experienced something similar, please share.

If the reason of the reset is because you’ve lost your password, there’s an easier trick too – the admin-account password is stored in plain text on the server (don’t ask why …), and can easily be retrieved.

To find out the current password, look at the contents in /etc/psa/.psa.shadow as a root account.

[root@vps bin]# cat /etc/psa/.psa.shadow
my-pass

This can be enough to regain access to your Plesk account. If you must perform a reset, you can go about it as follows. Go to /usr/local/psa/admin/bin/ .

[root@vps ~]# cd /usr/local/psa/admin/bin/

You’ll find a script there, titled “ch_admin_passwd“. Run it with the –help parameter to find out what it does.

[root@vps bin]# ./ch_admin_passwd –help

./ch_admin_passwd: Utility to set Plesk adminstrator’s password
Gets password from the environment variable PSA_PASSWORD
Password should be from 5 to 14 symbols and should not contain login name,
whitespace, quotes or national characters

Usage: ./ch_admin_passwd -h, –help
display this help and exit

So we need to define an environment variable called “PSA_PASSWORD“, which will be used by the script to reset the password.

[root@vps bin]# set PSA_PASSWORD=’my-pass’

There can be no spaces between “PSA_PASSWORD”, and the equality-sign (=). This will become your new pasword of the admin account in Plesk.

Now run the script, to do the actual reset.

[root@vps bin]# ./ch_admin_passwd

This can take a couple of seconds, depending on your server load. Afterwards, you can log in using your newly defined password. And to clean things up, it’s wise to remove the environment variable after the reset.

[root@vps bin]# set PSA_PASSWORD=

You can see if the reset went ok, by looking at the value in /etc/psa/.psa.shadow

[root@vps bin]# cat /etc/psa/.psa.shadow
my-pass

And it’s as simple as that.

There are several possible solutions, which can be tried harmlessly. First is to restart MySQL and PSA (Plesk Server Administrator).

/etc/init.d/mysql restart
/etc/init.d/psa restart

If that does not solve it, you can run the following commands to execute the statistics-tool in Plesk, which will re-calculate all stats (disk & bandwidth usage).

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e”update misc set val=’byte’ where param=’size_count_type’”
/usr/local/psa/admin/sbin/statistics

This will re-run all the statistics for the domains (and if you have a lot of domains, this can take a while) and Plesk will show correct disk- and bandwidth usage again.

One of the easiest things to try, and one that solves a lot of Plesk issues, is running the command that will re-configure all services on the server, according to the Plesk internal database. That database contains all settings for mailboxes, DNS-records, web-users, additional settings, …

Here’s how to run it

/usr/local/psa/admin/bin/websrvmng -av

It’s harmless – as your services installed should always be configured with the latest Plesk Database Information (this normally happens automatically).

If that doesn’t do the trick to get Horde Webmail back, you could try reading up on Common Problems With Horde Webmail and Plesk.

You can however, tune it further to include DNS Blacklists (or DNSBL) to make use of Spamhaus.org’s lists. You can also make it check for SPF records (the so-called Sender Policy Framework) with its senders, to make it even more strict.

These options can be found in your Plesk controlpanel, under “Server” > “Mail” > “Preferences”.

According to Spamhaus themselves, it’s advised to add the “zen.spamhaus.org” as a DNSBL address (a combination of all their major DNSBL’s). I have yet to play with the SPF-record spam protection – but I’ll make sure to write something extra about that in a couple of days.

First of all, you need to edit the VirtualHost of whatever domain you’re trying to enable this for. Seeing as Plesk would just overwrite your httpd.conf with the next change you make in the controlpanel, you need to use a seperate vhost.conf file.

The file to edit can be found in the following directory:

/var/www/vhosts/<my domain>/conf/vhost.conf

It’s possible the file doesn’t exist, just go ahead and create it. If it does exist, simply edit it. If you’re trying to enable this for a subdomain only, you should edit the following file.

/var/www/vhosts/<my domain>/subdomains/<subdomain-name>/conf/vhost.conf

Once you’re editting the file vhost.conf, add the following lines.

<Directory /var/www/vhosts/<my domain>/httpdocs>
        php_admin_value include_path "/var/www/vhosts/<my domain>/httpdocs/:/usr/share/pear/"
        php_admin_value open_basedir "none"
</Directory>

You can change the Directory-name to reflect whatever directory you’re trying to modify. For a subdomain, you should include the /subdomains/<subdomain-name>/ location as well.

The new vhost.conf only adds the location for the PEAR packages, being /usr/share/pear/. Make sure to keep your normal httpdocs directory in there too, otherwise your other includes will fail.

Now, you should let Plesk rebuild its configuration files in order to pick up the changes made in your vhost.conf, by running the following command.

/usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=my-domain-name

Replace “my-domain-name” with the actual domain name for which you want to enable PEAR. The command above will rebuild the vhost config for that specific domain. If you’re interested in rebuilding it for all your domains, you can use the shorter version.

/usr/local/psa/admin/sbin/websrvmng -a -v

At the beginning I said Plesk has a lot of PEAR Packages installed by default, and that’s true. They are however, in a different directory. You can find them all here.

/usr/share/psa-pear/

You can copy any package you want or need to /usr/share/pear/, to enable them.

I suggest you update your PEAR packages before you get started, because Plesk may install quite a few of time, but they’re mostly outdated anyway. Grab your copies from the PEAR-website, and replace the files on your server.

That’s pretty much the simplest way to do it.

You’ll get this error, probably because you’re trying to create a new mailbox for an e-mail address that was once an alias to another mailbox, but was removed.

Example: you have the mailbox “john@domain.com”, and you added an alias called “info@domain.com” to this address. Now you want to create a different mailbox for “info@domain.com”, so you delete the alias from “john@domain.com”, to create a new mailbox. That’s probably when you’ll see this error.

Solution:
Log in remotely to your windows server where the Plesk is installed, and browse to “C:\Program Files\SWsoft\Plesk\Mail Servers\Mail Enable\Config\Postoffices\<your domain>\”.

You’ll find 3 files there, called “default.mai“, “mailbox.sav” and “mailbox.tab“. Open each one with notepad or wordpad, or another text editor, and find every line that says “info@domain.com” (this is the alias you once created, but are now trying to remove completely, in order to create the mailbox). You’ll see them occur in those files (it’s possible you’ll only find it in one of those 3).

Delete each line that has that e-mail address in it.

Now try to re-create the new mailbox through the Plesk web interface, you’ll see it no longer generates an error but creates the mailbox as you would expect.

First of all, make sure the mailboxes exist.

[root@vps]# cd /var/qmail/mailnames/<domain>/<mailboxname>

If it doesn’t, then you can safely delete the mailbox you see in Plesk, and re-create one. This can occur when you create a mailbox, but for some reason qmail can’t actually create it. Plesk thinks it’s created, thus adds it to its internal database, and you think it exists. Well, it doesn’t :-) .

Another way to fix invalid mailboxes, is to run the Plesk qmail utility. This will check all the qmail config files, and rebuild them according to the Plesk database. This will also fix the Spamassasin config files.

[root@vps]# /usr/local/psa/admin/sbin/mchk ---with-spam

Here’s a list of other possible parameters, you can use it to check only mailboxes (without spamassasin), or only spamassasin (without the mailboxes).

[root@vps sbin]# ./mchk
Usage: mchk [OPTION]
  Restore settings for all mailboxes.
  --without-spam [--daemon-mode]
         restore all settings except for SpamAssassin configuration
  --with-spam [--daemon-mode]
         restore all settings
  --spam-only [--daemon-mode]
         restore only SpamAssassin settings

Other error messages that could indicate this problem (but which might as well mean something entirely different, just for fun) are:

• Hi. This is the qmail-send program at <myserver>. I’m afraid I wasn’t able to deliver your message to the following addresses. This is a permanent error; I’ve given up. Sorry it didn’t work out
• Sorry, no mailbox here by that name. (#5.1.1)