For example, a Microsoft Outlook client running on Windows 7 would report:

Receiving reported error (0x800CCC1A) Your server does not support the connection encryption type you have specified. Try changing the encryption method. Contact your mai server administrator or Internet service provider (ISP) for additional assistance.”

Despite the minor version number increment, Dovecot 2.4 is a major update which has significant breaking changes to the structure of the configuration files and thus the old configuration files need to be carefully converted in order to work with Dovecot 2.4.

Dovecot 2.4 should really have been called Dovecot 3.0. I have no idea why Open-Xchange considered a minor version number bump to be appropriate for this release.

The default TLS ciphers enabled for Dovecot (both 2.3 and 2.4) on cPanel are:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES256-GCM-SHA384

This is almost identical to the very useful Mozilla “Intermediate” list, except that the DHE-RSA-CHACHA20-POLY1305 cipher is missing.

Windows 7 has very poor support for modern cryptography since it went end-of-life in January 2020 and so hasn’t received any updates for 6 years now.

The supported cipher suites advertised in the SSL/TLS handshake by a Windows 7 client device are:

Most of these are now considered insecure and thus are not enabled on the server side.

The overlap between the TLS ciphers supported by the client and the TLS ciphers which are allowed on the server side is just four ciphers:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES128-GCM-SHA256

Unfortunately, the two ECDHE-ECDSA-* ones will only work if you are using ECDSA SSL certificates. If you are using RSA certificates then you can only use the DHE-RSA-* ones.
Still, we have TLS ciphers which are supported by both the client and the server so this should be working… why isn’t it?

Previously under Dovecot 2.3, cPanel had the following configuration in /etc/dovecot/dovecot.conf for the Diffie-Hellman parameters file necessary for the DHE-RSA-* ciphers to function:

# SSL DH parameters
# Generate new params with `openssl dhparam -out /etc/dovecot/dh.pem 4096`
# Or migrate from old ssl-parameters.dat file with the command dovecot
# gives on startup when ssl_dh is unset.
ssl_dh = </etc/dovecot/dh.pem

In Dovecot 2.4 this configuration directive changed to “ssl_server_dh_file” (see https://doc.dovecot.org/2.4.2/installation/upgrade/2.3-to-2.4.html#converted-settings) and it isn’t present anywhere in /etc/dovecot/ post-upgrade on cPanel servers.

As a random, aside; the old configuration “ssl_dh” option value was for the contents of the certificate, which could be read from a file with the redirect. The new “ssl_server_dh_file” option takes file path as the value, which Dovecot then reads itself. As such, when moving from 2.3 to 2.4 it’s important to ensure that you don’t copy over the less than symbol that precedes the path, otherwise Dovecot will try to read the contents of that file and treat those as the path that it should use.

In order to add the configuration for the Diffie-Hellman parameters file to the Dovecot 2.4 configuration yourself, you will need to make use of the cPanel configuration file templating system, otherwise any manual changes to the configuration files in /etc/dovecot/ will get overwritten the next time cPanel regenerates them.

First check if the /var/cpanel/templates/dovecot/main.local file already exists (for example if you already have custom Dovecot configuration or if you are using Imunify360). If not, then copy the file /var/cpanel/templates/dovecot/main.default to /var/cpanel/templates/dovecot/main.local and edit it in your favour editor to add the following configuration to the bottom of the file:

# Required for DHE-RSA-AES128-GCM-SHA256 and DHE-RSA-AES256-GCM-SHA384 ciphers needed for Windows 7 clients to work
ssl_server_dh_file = /etc/dovecot/dh.pem

Once you have modified the /var/cpanel/templates/dovecot/main.local file, you can run “/scripts/builddovecotconf” to regenerate the configuration files from your new template, followed by “/scripts/restartsrv_dovecot” to restart the Dovecot service.

IMAP and POP3 clients running on old devices such as Windows 7 should once again be able to connect as the DHE-RSA-* TLS ciphers that they rely on are functioning again.

The post cPanel Dovecot 2.4 upgrade breaking Windows 7 clients first appeared on Spheron1.

Traditionally you needed an old copy of macOS Server in order to get these APNs certificates, but it was also possible to obtain the certificates using third party scripts such as https://github.com/scintill/macos-server-apns-certs which had reverse engineered the Apple APIs for issuing certificates.
Unfortunately, in October 2024 Apple discontinued this API and so it was no longer possible to issue new APNs certificates for com.apple.mail, com.apple.calendar and com.apple.contact.

Whilst it is annoying that we can’t provide push notifications to Apple users anymore thanks to these changes, this actually becomes a service affecting problem when these certificates expire as it causes any cPanel servers still using the old Calendar and Contacts Server (CCS) plugin (which behind the scenes is the old open source Apple/Darwin Calendar and Contacts Server) to break as the “cpanel-ccs” service will stop and refuse to start with a message about the expired APNs certificates:

-- Unit cpanel-ccs.service has begun starting up.
Apr 22 17:57:34 myserverhostname.com ccs_init[24103]: Using /opt/cpanel-ccs/.develop/virtualenv/bin/python as Python
Apr 22 17:57:34 myserverhostname.com ccs_init[24103]: Starting server...
Apr 22 17:57:34 myserverhostname.com ccs_init[24103]: /opt/cpanel-ccs/bin/caldavd  -f /opt/cpanel-ccs/conf/caldavd-dev.plist -P caldav -t Combined
Apr 22 17:57:36 myserverhostname.com ccs_init[24103]: Reading configuration from file: /opt/cpanel-ccs/conf/caldavd-dev.plist
Apr 22 17:57:36 myserverhostname.com ccs_init[24103]: APNS certificate expired /var/cpanel/ssl/caldav_apns/cert.pem
Apr 22 17:57:36 myserverhostname.com systemd[1]: cpanel-ccs.service: control process exited, code=exited status=1
Apr 22 17:57:36 myserverhostname.com systemd[1]: Failed to start Apple Calendar Server.
-- Subject: Unit cpanel-ccs.service has failed

Frustratingly, cPanel doesn’t provide a way to remove an existing APNs certificate, only to install new ones… given that no new APNs certificates can be issued, this leaves us rather stuck!
Sadly this kind of lack of attention to detail for basic management tasks is common throughout cPanel.

Even more frustratingly, cPanel seem to have removed all of their documentation about the APNs feature, so the only evidence that it ever existed are some very old posts on their badly mangled forum.

After a bit of poking around, I managed to find that you can manually remove the /var/cpanel/ssl/*apns/*.pem* certificate files and then update the CCS config in /opt/cpanel-ccs/conf/caldavd-dev.plist to remove any mention of them with the following commands:

rm -f /var/cpanel/ssl/*apns/*.pem*
/opt/cpanel-ccs/bin/rebuildccsconfig
systemctl restart cpanel-ccs.service

After this, the “cpanel-ccs” service will run normally again so CalDAV and CardDAV services are restored for all users.

The one last thing to do is go to Service Configuration -> Service Manager in WHM and disable “APNSPush” under “tailwatchd”.

The post Removing APNs certificates in cPanel first appeared on Spheron1.

The following was being logged in /var/logs/maillog for each attempt:

plesk sendmail[1628571]: handlers_stderr: ERROR:__main__:Rejecting message: system user uid='<user ID>’ is not allowed to send mail
plesk sendmail[1628571]: handlers_stderr: DATA REPLY:554:5.7.0 Your message could not be sent. The user <user name> is not allowed to send email.
plesk sendmail[1628571]: handlers_stderr: REJECT
plesk sendmail[1628571]: REJECT during call ‘limit-out’ handler

When calling sendmail from the command line, logged in as the user in question, I got:

Mail handler ‘limit-out’ said: REPLY:554:5.7.0 Your message could not be sent. The user logbookloans247 is not allowed to send email.

Plesk have a particularly useless knowledge base article which says that this is due to the mail service being disabled for the domain; https://support.plesk.com/hc/en-us/articles/360002410214-Unable-to-send-an-email-via-Wordpress-Rejecting-message-system-user-uid-xx-is-not-allowed-to-send-mail

This is nonsense – disabling the mail service is routine when email for a domain is hosted externally and so the server shouldn’t act as the final destination for email to this domain so as not to cause problems for any locally generated email destined for that domain.
Just to double check, I enabled the mail service on the domain, but unsurprisingly the problem persisted.

I checked several other Plesk servers and there were no other occurrences of this message in the mail logs, so this appeared to be an account specific problem.
I therefore tried fiddling with the outbound mail limits for the domain and the subscription, but no luck.

Eventually I stumbled on some users on the Plesk forums having a similar but unrelated problem, however this led me to the /usr/local/psa/admin/sbin/mailmng-outgoing command and through a bit of experimentation I found that the system user seemed to be missing, which I was able to add with the following command:

/usr/local/psa/admin/sbin/mailmng-outgoing --add-sysuser --main-domain-name=<domain name> --sysuser=<system user>

After doing this, sendmail and thus mail() worked as normal.

The post Sendmail on Plesk – user is not allowed to send mail first appeared on Spheron1.

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
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE=”C.UTF-8″
LC_NUMERIC=”C.UTF-8″
LC_TIME=”C.UTF-8″
LC_COLLATE=”C.UTF-8″
LC_MONETARY=”C.UTF-8″
LC_MESSAGES=”C.UTF-8″
LC_PAPER=”C.UTF-8″
LC_NAME=”C.UTF-8″
LC_ADDRESS=”C.UTF-8″
LC_TELEPHONE=”C.UTF-8″
LC_MEASUREMENT=”C.UTF-8″
LC_IDENTIFICATION=”C.UTF-8″
LC_ALL=

$ locale -a
C
C.UTF-8
POSIX
en_US.utf8

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:
language-pack-en-base
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 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 language-pack-en-base all 1:18.04+20180712 [419 kB]
Get:2 http://archive.ubuntu.com/ubuntu 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
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IL
en_IL.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX
$ 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.

The post Changing the locale in Ubuntu Server first appeared on Spheron1.

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 cPanel.com. 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.

The post cPanel 54 first appeared on Spheron1.

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.

The post Parallels Plesk hanging on login first appeared on Spheron1.

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…

The post cPanel breaking Dovecot in 11.40 first appeared on Spheron1.

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 http://bin.soluslabs.com/1083/38662948/raw/ 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:

XENFIXCENTOS6DF=”1″

Then run these commands:

wget https://www.dropbox.com/s/j8nu3ye09x9ehwq/command.php -O /usr/local/solusvm/www/command.php
wget https://www.dropbox.com/s/93hsnzzmpwny3r4/solusvmc-xen -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.

The post SolusVM displaying wrong disk usage statistics for Xen PV VMs first appeared on Spheron1.

/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

The post ImageMagick and PHP 5.4 first appeared on Spheron1.

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.

The post Not able to unsuspend a domain in Parallels Plesk first appeared on Spheron1.