Archive for the ‘cPanel/WHM’ Category

Changing the locale in Ubuntu Server

Wednesday, April 3rd, 2019

When logging into any cPanel server via SSH from an Ubuntu jump server I was seeing some strange warnings from Perl which I didn’t see when logging in from my laptop running macOS:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).

After a quick rummage, I found that the reason was that the “LANG” environment variable on my laptop was defaulting to “en_GB.UTF-8”, whilst on the Ubuntu jump server it was “C.UTF-8”.

The cPanel server runs some Perl stuff when bash starts and if it doesn’t like your locale settings, then it spits out these warnings.

The “LANG” environment variable is part of the locale system and so the best way to fix this is to update the locale settings configured on the Ubuntu jump server.

By default, SSH on both macOS and Ubuntu is configured to send the local “LANG” and “LC_*” environment variables used for locale settings to the remote system.

You can use the “locale” command to see your current locale settings as well as “locale -a” to see installed locales.

$ locale

$ locale -a

In my case I wanted to use en_GB.utf8, which wasn’t installed. You can use the “locale-gen” command to generate locales, but they are also provided in official Ubuntu packages , so I installed the “language-pack-en” package from the Ubuntu repositories using APT.
This added several English locales and then I could reconfigure Ubuntu to use the one that I needed.

$ apt-get install language-pack-en
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following additional packages will be installed:
The following NEW packages will be installed:
language-pack-en language-pack-en-base
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 420 kB of archives.
After this operation, 3756 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 bionic-updates/main amd64 language-pack-en-base all 1:18.04+20180712 [419 kB]
Get:2 bionic-updates/main amd64 language-pack-en all 1:18.04+20180712 [1904 B]
Fetched 420 kB in 0s (3606 kB/s)
Selecting previously unselected package language-pack-en-base.
(Reading database … 50814 files and directories currently installed.)
Preparing to unpack …/language-pack-en-base_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en-base (1:18.04+20180712) …
Selecting previously unselected package language-pack-en.
Preparing to unpack …/language-pack-en_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en (1:18.04+20180712) …
Setting up language-pack-en (1:18.04+20180712) …
Setting up language-pack-en-base (1:18.04+20180712) …
Generating locales (this might take a while)…
en_AG.UTF-8… done
en_AU.UTF-8… done
en_BW.UTF-8… done
en_CA.UTF-8… done
en_DK.UTF-8… done
en_GB.UTF-8… done
en_HK.UTF-8… done
en_IE.UTF-8… done
en_IL.UTF-8… done
en_IN.UTF-8… done
en_NG.UTF-8… done
en_NZ.UTF-8… done
en_PH.UTF-8… done
en_SG.UTF-8… done
en_ZA.UTF-8… done
en_ZM.UTF-8… done
en_ZW.UTF-8… done
Generation complete.

$ locale -a
$ update-locale LANG=en_GB.utf8

The locale settings are stored in “/etc/default/locale“, so you can either edit this file manually or use the handy “update-locale” utility to do it for you.
Either way, once you start a new session, you are using the new locale settings and Perl no longer complains when you SSH to a cPanel server.

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.

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…

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

Remove CDP 2.0 cPanel integration

Sunday, June 19th, 2011

A handy feature of R1Soft CDP Server 2.0 (now known as Enterprise Edition) is that it can integrate with cPanel so that your users can restore their own files from your backups using a self service interface. If you want to remove this integration for any reason, then R1Soft provide a BASH shell script to do this for you:


This script doesn’t always work for one reason or another, so the other way of doing this is to manually call the cPanel plugin uninstaller:

/usr/local/cpanel/bin/unregister_cpanelplugin /var/cpanel/registered_cpanelplugins/righteousbackup

This is particularly helpful if you forgot to uninstall the cPanel integration before upgrading to R1Soft CDP 3.0 or thought that the r1soft-uninstall-buagent utility would do it for you when removing the R1Soft CDP 2.0 agent (unfortunately it doesn’t, but it does helpfully remove the script).

Unfortunately the cPanel integration in R1Soft CDP 3.0 is severely lacking compared to R1Soft CDP 2.0 and in my opinion is virtually useless in it’s current form.

As the control panel integration system is a pretty new feature in R1Soft CDP 3.0 (it was missing entirely from the initial release), hopefully it will be bolstered in subsequent R1Soft CDP 3.0 releases to restore it to the same level of functionality as was formerly available in R1Soft CDP 2.0.

cPanel root partition space warning disabling operation of some features in WHM

Thursday, February 3rd, 2011

If you manage to accidentally fill up the root partition on your cPanel/WHM server, then WHM helpfully disables some features such as creating and terminating (deleting) accounts so that you don’t end up with half of an account. You will see a message something along the lines of this in WHM when attempting a restricted function:

The / partition on this server is running out of disk space. WHM operation has been temporarily suspended to prevent something bad from happening. Please ask your system admin to remove any files not in use on that partition.

Annoyingly, WHM doesn’t notice as soon as you free up some disk space, so not only can you not carry out some essential maintenance tasks until WHM next checks the free disk space but any of your customers with access to WHM (such as resellers) might come across this potentially embarrassing message!

cPanel stores a cache of it’s disk space calculation (basically the output of df) in “/root/.cpanel/datastore/_bin_df_-P_-k_-l” so you can either regenerate this file with the /usr/local/cpanel/bin/build_global_cache script, or alternatively just move/delete this file to get WHM back to normal operation.

cPanel Native SSL support failed error

Friday, December 31st, 2010

If your cPanel/WHM install randomly sends you an e-mail one day along the lines of:

Native SSL support failed to pass the startup test. stunnel was started instead.
The exact error was: [linktest=/usr/local/cpanel/bin/linktest-ssl: error while loading shared libraries: /usr/local/cpanel/perl/Net/SSLeay/ cannot open shared object file: No such file or directory
] [binary=/usr/local/cpanel/cpsrvd-ssl] [cpsrvd=/usr/local/cpanel/cpsrvd-ssl: error while loading shared libraries: /usr/local/cpanel/perl/Net/SSLeay/ cannot open shared object file: No such file or directory

You should attempt run /usr/local/cpanel/bin/nativessl-install or submit a support request at

Then hopefully the following will restore it to it’s previous working state:

perl -MCPAN -e ‘install ExtUtils::Install’

I have no idea what causes this or why /scripts/checkperlmodules doesn’t flag the ExtUtils::Install Perl module as missing, but it seems to fix the problem even when using perl588installer.tar.gz from to re-install the cPanel provided version of Perl and associated CPAN modules doesn’t.

cPanel/WHM and yum-updatesd

Monday, March 15th, 2010

In my continuing fight with yum-updatesd, I found that on servers with cPanel/WHM installed it was crashing with mysterious Python errors:

root@tma03 [/etc/yum]# yum-updatesd –debug –no-fork
Traceback (most recent call last):
File “/usr/sbin/yum-updatesd”, line 35, in ?
import dbus
File “/usr/lib64/python2.4/site-packages/dbus/”, line 1, in ?
from _dbus import *
File “/usr/lib64/python2.4/site-packages/dbus/”, line 48, in ?
from proxies import *
File “/usr/lib64/python2.4/site-packages/dbus/”, line 2, in ?
import introspect_parser
File “/usr/lib64/python2.4/site-packages/dbus/”, line 1, in ?
import libxml2
File “/usr/lib64/python2.4/site-packages/”, line 215
TabError: inconsistent use of tabs and spaces in indentation

In the end, I fixed this by forcing a re-install of the dbus-python and libxml2-python RPMs from the official CentOS mirrors. In my case, this was:

rpm –force -hUv

Adjust using your mirrors, distribution, version, architecture and RPM revision as appropriate.
Also, always remember to check for updates after manually re-installing RPMs from the OS repository.

I have no idea what cPanel/WHM does to break Python like this or if updates to cPanel are going to break yum-updatesd again in the future, but I have fixed this on several cPanel 11.25 boxes now!
I know cPanel likes to mess with system files, but these RPMs aren’t in the exclude list that the cPanel installer adds to /etc/yum.conf and forcing a re-installation of them seems to fix yum-updatesd.