Archive for the ‘Control panels’ Category

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/SSLeay.so: 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/SSLeay.so: 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 https://tickets.cpanel.net/submit/

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

perl -MCPAN -e ‘install ExtUtils::Install’
/usr/local/cpanel/bin/nativessl-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 layer1.cpanel.net to re-install the cPanel provided version of Perl and associated CPAN modules doesn’t.

Parallels Plesk for Windows upgrade and lots of session files

Monday, December 27th, 2010

Be careful when running the Parallels Plesk update utility on Windows servers if you have a large number of files in “C:\Program Files (x86)\Parallels\Plesk\admin\sessions” as once it has finished the upgrade the utility will try and clear this directory before letting you do anything else, including the mandatory reboot. It seems that it is quite easy for there to be hundreds of thousands of files in this folder, which in turn means that this part of the upgrade process can take well over an hour even on a decent machine!

WHMCS 4.41 and the Plesk server module

Sunday, December 19th, 2010

WHMCS version 4.41 has split the Plesk server automation module out into three separate versions; plesk8, plesk9 and plesk10, but the upgrade script doesn’t handle changing the automation module settings for either your servers or your products/services.

As a result of this short sightedness on the developer’s part you will loose all automation of your Plesk servers (account creation, suspension, termination, statistics updates etc.) and start experiencing fatal PHP errors in both the admin and client areas of WHMCS where the functions provided by the old “plesk” module are used (which is basically any area using products/services or servers defined with the “plesk” module) unless you retain the generic “plesk” module from your previous WHMCS 4.31 install.

As copying over the “modules/servers/plesk” folder from WHMCS v4.31 or symlinking the appropriate folder of one of the new modules to “modules/servers/plesk” seems like a massive dirty hack to me, instead I decided to do what the WHMCS 4.41 installer should have done in the first place and fix the database to use the correct version of the new Plesk server module.

For me the new “plesk9″ module is the one to use, but you can adjust the following SQL appropriately to suit your needs (remember to backup your database however you see fit before you begin!):

UPDATE tblproducts SET servertype=’plesk9′ WHERE servertype=’plesk’;

and

UPDATE tblservers SET type=’plesk9′ WHERE type=’plesk’;

As usual with WHMCS, there are no mention of any changes to the Plesk module in the release notes for version 4.41.

Parallels Plesk 9.5.1/9.5.2 and Greylisting

Friday, June 11th, 2010

In April’s Plesk 9.5.1 update (following on from 9.3.x – apparently Parallels can’t count so just skipped 9.4.x and 9.5.0 entirely…) they managed to seriously break one of the great Plesk 9 features for Postfix users… greylisting!

One of the big improvements when Plesk 9 was released (apart from ditching QMail!) was that it no longer relied upon unsupported third party software such as QGrey to add greylisting features. The big benefit of this was that the greylisting was tied in the with authentication of mail users, so users who authenticated to your SMTP server in order to use it as a relay automatically bypassed the greylisting filters.

The use of third party greylisting in Plesk 8.x was the source of much frustration from users who were trying to send e-mails and were getting unhelpful error messages from their e-mail clients. This puts server administrators in a difficult position; deal with the user complaints, or disable greylisting and put up with a massive increase in spam e-mail.

In Plesk 9.5.1 this feature mysteriously stopped working. At first Parallels claimed that greylisting was working as designed, but then admitted that it was a bug and they would fix it. The Plesk 9.5.2 release came and went with no fix and no word from Parallels. In the end, it was well over a month from Pleks 9.5.1 being released and the bug first being reported to a patch being available.

The fix that they have released isn’t released as a hotfix and so doesn’t show up in the normal Plesk update process either from the command line auto-installer or the Plesk web GUI’s udpate manager, nor is it applied as part of a fresh install. It’s not even on the Parallels Knowledge Base, you have to go on their forums and find it in a thread by a Parallels member of staff known as “IGorG” called “Workarounds” in the “Parallels Plesk Panel 9.5 for Linux/UNIX Suggestions and Feedback” forum.

Even once you have located the ZIP file containing the patched code and got your forum login to work long enough for you to download it without getting a “Can’t create new user ” error, Parallels have only release the fix for certain platforms (in particular, CentOS 4.x and 5.x both 32-bit and 64-bit as well as Debian 5 64-bit only) and they don’t seem to have any intention of releasing the patch for the other Linux/UNIX platforms supported by Plesk 9.x (SuSE, openSuSE, FreeBSD, Fedora, Debian 3.x & 4.x, Debian 5.x 32-bit, Ubuntu or CloudLinux).

If you are lucky enough to be on one of the supported platforms for which they have released a patch then you can download the ZIP file with the new postfix-queue files from the “official” post on the Parallels forum at http://forum.parallels.com/showpost.php?p=413387&postcount=62

Once you have copied it onto your server and extracted the contents, you should find several folders which correspond to the patched platforms (Cos4x32, Cos4x64, Cos5x32, Cos5x64 and Deb5x64), each of which has a fixed copy of the “postfix-queue” binary inside.

Back up your current postfix-queue from “/usr/lib/plesk-9.0/postfix-queue” (32-bit copies of Plesk) or “/usr/lib64/plesk-9.0/postfix-queue” (64-bit copies of Plesk) to somewhere safe and then copy the postfix-queue file from the appropriate directory over the /usr/lib/plesk-9.0/postfix-queue or /usr/lib64/plesk-9.0/postfix-queue file and restart the Postfix service.

Your authenticated users should now be able to send e-mail again without having to wait for the greylisting timers.

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/__init__.py”, line 1, in ?
from _dbus import *
File “/usr/lib64/python2.4/site-packages/dbus/_dbus.py”, line 48, in ?
from proxies import *
File “/usr/lib64/python2.4/site-packages/dbus/proxies.py”, line 2, in ?
import introspect_parser
File “/usr/lib64/python2.4/site-packages/dbus/introspect_parser.py”, line 1, in ?
import libxml2
File “/usr/lib64/python2.4/site-packages/libxml2.py”, line 215
pass
^
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 http://mirrors.freethought-internet.co.uk/centos/5/os/x86_64/CentOS/dbus-python-0.70-7.el5.x86_64.rpm http://mirrors.freethought-internet.co.uk/centos/5/os/x86_64/CentOS/libxml2-python-2.6.26-2.1.2.8.x86_64.rpm

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.

@mail in Plesk 9.3

Friday, March 5th, 2010

I recently upgraded a server to Plesk 9.3 only to find that it broken @mail. The list of available webmail clients no longer has @mail in it and trying to remove the psa-atmail RPM failed with a script error.

In the end, I had to force the removal of the RPM with the –noscripts option and then go and manually delete /var/www/atmail as well as any entries in /etc/psa-webmail/atmail, /etc/psa-webmail/atmailcom, /etc/psa/webmail/atmail and /etc/psa/webmail/atmailcom before I could get the RPM to re-install correctly.
Even then, the RPM install failed with “Unable to get options for atmail webmail” and I had to run “/usr/local/psa/admin/bin/webmailmng –install –name=atmail” to get it back in to the list of available webmail clients.

It seems that this has all come about with Parallels moving the webmail config files from /etc/psa-webmail/ to /etc/psa/webmail/ and botching up the RPMs somehow.

Per-domain/per-account settings for Plesk 9′s greylisting

Thursday, February 4th, 2010

Plesk 9 introduced the very useful feature of greylisting for the Postfix SMTP server (and presumably the QMail one as well, but I only use Postfix as QMail gives me a headache!).

Greylisting basically sends a “resource temporarily unavailable, please try again later” message whenever someone connects and tries to deliver an e-mail. For legitimate SMTP servers, this isn’t a problem; they will do as the server and the SMTP RFC says and try again later.

Spammers on the other hand don’t generally retry as they are just focused on blasting out as many e-mails as possible to as many addresses as possible. They don’t have time to come back to your server later as all of the retries would tie them up and prevent them from sending to other potentially reachable servers. They also generally use poorly written software that doesn’t conform to standards.

The greylisting software keeps track of the IP addresses trying to send e-mails through the SMTP server that it is protecting and after a resonable amount of time (say 15 minutes or so) it will allow re-delivery attempts to pass through.
If a server tries to re-connect too soon and/or too frequently after being told to try again later, then it is penalised by the greylisting software.

The only two downsides to greylisting are that some legitimate e-mail servers don’t retry sending e-mails (so you have to whitelist them in order to be able to receive e-mail from them) and that greylisting slows down e-mail delivery as you have to wait for the sending server to retry.

The Plesk web interface is a bit limited when it comes to greylisting, but luckily (as with most Plesk features) there are comprehensive CLI tools to accomplish what you need. In this case, the “grey_listing” command, which for CentOS/RHEL systems can be found in /usr/local/psa/bin/grey_listing

Some useful commands:

Show server wide settings:

/usr/local/psa/bin/grey_listing –info-server

Show per domain settings:

/usr/local/psa/bin/grey_listing –info-domain spheron1.co.uk

Show per e-mail address settings:

/usr/local/psa/bin/grey_listing –info-mailname postmaster@spheron1.co.uk

Enable server wide greylisting:

/usr/local/psa/bin/grey_listing –update-server -status on

Disable greylisting per-domain:

/usr/local/psa/bin/grey_listing –update-domain spheron1.co.uk -status off

Set the time to greylist new IP addresses for (in minutes):

/usr/local/psa/bin/grey_listing –update-server -grey-interval 5

Set the expiry time for allowed IP addresses (in minutes):

/usr/local/psa/bin/grey_listing –update-server -expire-interval 43200

Set the time to penalise IP addresses for (in minutes):

/usr/local/psa/bin/grey_listing –update-server -penalty-interval 2

Enable penalising of IP addresses:

/usr/local/psa/bin/grey_listing –update-server -penalty-status on

Whitelist e-mail from all @gmail.com addresses to postmaster@spheron1.co.uk:

/usr/local/psa/bin/grey_listing –update-mailname postmaster@spheron1.co.uk -whitelist add:*@gmail.com

Server wide blacklist e-mail from postmaster@hotmail.com:

/usr/local/psa/bin/grey_listing –update-server -blackelist add:postmaster@hotmail.com