Archive for the ‘Control panels’ Category

cPanel 54

Friday, October 16th, 2015

Yesterday cPanel laid out the upcoming changes in cPanel 11.54, or just cPanel 54 as it’s now known (see Whilst light on any details, there are at least some interesting tidbits.

The new versioning system
This makes very little real world difference, but I can’t help but feel like they’re following Google Chrome and Mozilla Firefox in a race to have the largest possible version number!

X3 being retired
Finally! X3 is an absolutely horrible theme which provides a truly terrible experience for users and I’ll be glad to see the back of it at long last!

Paper Lantern becoming the only choice
Hopefully with Paper Lantern becoming the only cPanel user interface (and dropping the silly “Paper Lantern” name!), it will start to move away from just being a tarted up version of X3 with some nicer icons and towards a more friendly, usable interface which doesn’t just feel the need to dump everything on one page!

cPassword, OpenID Connect and 2FA
I’ve got mixed feelings about this – the new cPassword interface sounds like a great idea, but the OpenID Connect feature sounds like a security nightmare, particularly with the default service being hosted externally on At least we’re going to have the option of replacing it with our own backend (as well as being able to disable it altogether, hopefully!).
That said, Two factor authentication is a great addition, although I suspect that we are going to see more support tickets as people lose their phones etc. and lock themselves out of their hosting!

IPv6 only
cPanel were massively behind the game when it came to adding full IPv6 support, so it’s good to see them adding the ability to run completely without IPv4 now, particularly given the recent IPv4 exhaustion at ARIN.

Nginx front end
Good to see cPanel finally starting to catch up with Odin Plesk on this one! Hopefully we’ll see support for more complex configurations in future versions.

Directory Syncing
This could be quite useful depending on how it’s implemented. I suspect that it will be some form of asynchronous rsync based system, possibly with FTP and/or inode based hooks. Hopefully it won’t just be a periodic cron job task!

EasyApache 4
Hopefully EasyApache 4 will move towards using the operating system package management (RPM and YUM) for Apache and PHP, instead of insisting on needlessly compiling everything from scratch. This is one of my biggest pet peeves with cPanel at the moment – it adds needlessly complexity to system administration, makes simple tasks like adding an Apache module or PHP extension slow and laborious and even makes installing cPanel pointlessly time consuming. If they have finally caught up with how the rest of the world has been working for the past decade (or more) then it will be great news!

Courier support finally being dropped
Dovecot beats Courier hands down, so it makes sense to stop supporting Courier and move everyone over to Dovecot. There really is little point in spending the extra development effort support two mail servers, so I’m a bit surprised that it has taken this long.
I wonder if we’ll continue to see support for both ProFTPD and Pure-FTPd as well as BIND/named, NSD and MyDNS in future or if they will also move those towards only supporting a single daemon.

Parallels Plesk hanging on login

Friday, June 27th, 2014

I recently came across a strange problem when setting up a new Windows Server running Parallels Plesk 12.

Everything was working fine to being with, and then suddenly Parallels Plesk started behaving strangely. I would select some items in a list and press remove and they would be greyed out as if the AJAX had fired in the background, but they wouldn’t be removed from the list until refreshing the page.

Wondering if this was some kind of browser problem as I was using Apple’s Safari, I fired up Mozilla’s Firefox but was somewhat surprised that I couldn’t get past the login screen.

The login page loads, but once I’d entered the username and password and pressed “Log In”, the page would just hang, loading indefinitely until it eventually times out.

The CPU and memory usage on the server were fine. The services were all running correctly. What’s going on?

After a quick look in “C:\Program Files (x86)\Parallels\Plesk\admin\logs\php_error”, it was pretty obvious that the recently installed Parallels Panel Mobile Center extension wasn’t working properly, as there were lots of errors about being unable to access files in “C:\Program Files (x86)\Parallels\Plesk\var\modules\plesk-mobile”.

Deleting the “C:\Program Files (x86)\Parallels\Plesk\var\modules\plesk-mobile” folder at least allowed me to log back in to the Parallels Plesk control panel, however the Parallels Panel Mobile Center extension couldn’t be removed.

After a bit of digging, it seems that the permissions on “C:\Program Files (x86)\Parallels\Plesk\var\modules\” aren’t set correctly out of the box and the “psaadm” user needed to be given write access to this folder in order to create or remove the files and folders for extensions when they are installed/uninstalled.

Once the permissions had been corrected, I was able to remove and then reinstall the Parallels Panel Mobile Center extension successfully.

cPanel breaking Dovecot in 11.40

Thursday, January 2nd, 2014

Recently I’ve had a couple of cases where cPanel randomly breaks Dovecot with one of the cPanel 11.40.x updates.

In one of these cases, cPanel actually uninstalled the Dovecot RPM as part of the automated, overnight upcp process! In the other cases, Dovecot was still running and accepting connections, but POP3/IMAP clients were getting messages that their passwords were wrong.

Reinstalling Dovecot if upcp has decided to remove it for some reason is quite simple – just use the cPanel script to check and repair their RPMs:

/scripts/check_cpanel_rpms –fix

Whilst the Dovecot RPM is now installed, chances are that Dovecot is still left in a broken state with any login attempt failing and messages like this in /var/log/maillog:

dovecot: auth: Fatal: execv(/usr/local/cpanel/bin/dovecot-wrap) failed: Permission denied

If you look at the ownership and permissions on /usr/local/cpanel/bin/dovecot-wrap, you’ll find that it’s root:root instead of root:dovecot and so you need to run the following in order to fix the ownership:

chgrp dovecot /usr/local/cpanel/bin/dovecot-wrap

At this point, you won’t be seeing any of the permission errors in the maillog, but you’ll still be seeing failed authentication attempts. Now you want to trick cPanel into thinking that the RPM has been removed so that it will try and re-install it. This should mean that the scripts from the RPM are executed without replacing any of the files:

rpm -e –nodeps –justdb dovecot
/scripts/check_cpanel_rpms –fix

If you are still having problems at this point, then try running the following to set the setuid flag for the owner on the script:

chmod u+s /usr/local/cpanel/bin/dovecot-wrap

Then you just need to re-run the above RPM trick and Dovecot should spring back into life with successful authentication attempts being logged into the maillog.

According to cPanel support, this is a “known issue” which has somehow made its way through the EDGE, CURRENT and RELEASE tiers into the STABLE tier…

SolusVM displaying wrong disk usage statistics for Xen PV VMs

Sunday, December 29th, 2013

Recently some of our Xen PV VMs started to show strange disk space usage statistics in SolusVM – despite there being plenty of space left on the disk in the VM, SolusVM was reporting that the disk was nearly full!

I struggled to find any public information about this, but apparently it is a known problem with SolusVM and the version of the “df” utility used in RHEL/CentOS 6.5. There have been some slight changes to the way that df displays its output and this causes SolusVM to interpret the disk usage figures incorrectly.

SolusLabs have posted a workaround for this at and I’m reproducing it here for posterity as well as in the hope that it will get indexed:

Fix for Xen PV disk usage showing 100% when using a CentOS 6.5 host node

The “df” output in CentOS 6.5 has changed. You may notice this when you upgrade you’re host node from CentOS 6.4. All the Xen PV virtual servers will show 100% disk space used.

On the affected host node edit /usr/local/solusvm/data/advanced.conf and add the following line:


Then run these commands:

wget -O /usr/local/solusvm/www/command.php
wget -O /usr/local/solusvm/core/solusvmc-xen
chmod 6777 /usr/local/solusvm/core/solusvmc-xen

Now when you reboot a virtual server (with the reboot button) the disk usage should update correctly.

ImageMagick and PHP 5.4

Friday, September 13th, 2013

When building the PHP imagick module for ImageMagick on a server running PHP 5.4 (a cPanel/WHM box in this case), you receive the following error:

/root/tmp/pear/imagick/imagick_class.c: In function ‘zim_imagick_setfont’:
/root/tmp/pear/imagick/imagick_class.c:1442: error: ‘struct _php_core_globals’ has no member named ‘safe_mode’
/root/tmp/pear/imagick/imagick_class.c:1442: error: ‘CHECKUID_CHECK_FILE_AND_DIR’ undeclared (first use in this function)
/root/tmp/pear/imagick/imagick_class.c:1442: error: (Each undeclared identifier is reported only once
/root/tmp/pear/imagick/imagick_class.c:1442: error: for each function it appears in.)
/root/tmp/pear/imagick/imagick_class.c:1442: error: ‘CHECKUID_NO_ERRORS’ undeclared (first use in this function)
/root/tmp/pear/imagick/imagick_class.c: In function ‘zim_imagick_setimageprogressmonitor’:
/root/tmp/pear/imagick/imagick_class.c:9534: error: ‘struct _php_core_globals’ has no member named ‘safe_mode’
/root/tmp/pear/imagick/imagick_class.c:9534: error: ‘CHECKUID_CHECK_FILE_AND_DIR’ undeclared (first use in this function)
/root/tmp/pear/imagick/imagick_class.c:9534: error: ‘CHECKUID_NO_ERRORS’ undeclared (first use in this function)
make: *** [imagick_class.lo] Error 1
ERROR: `make’ failed

The solution is to install the beta version of the module instead:

pear config-set preferred_state beta
pecl install imagick

Not able to unsuspend a domain in Parallels Plesk

Saturday, May 25th, 2013

If you are seeing the following unhelpful message when trying to unsuspend a domain in Parallels Plesk running on Windows Server:

Warning: The domain is still suspended for the following reason: This user account and user’s domain were suspended

Then you will need to use the command line domain.exe tool to manually unsuspend the domain:

“C:\Program Files (x86)\Parallels\Plesk\admin\bin\domain.exe” –on

I’ve not seen the same behaviour on a Linux based Parallels Plesk server, but that’s not to say that it doesn’t also suffer from the same problem.

Scheduled backups failing in Plesk 9.5

Saturday, 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

Thursday, 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

Monday, 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

SolusVM Nginx PHP bug

Monday, 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