Category Archives: cPanel/WHM

Databases missing from cPanel after MySQL upgrade !

A weird situation is when you can see the databases, its tables and so on from phpmyadmin of the concerned cPanel account or even from the backend, but is actually found missing under the ‘Databases’ section.

This issue occurs due to the lack of mapping of databases. Use these commands to re-create the mapping :

# /usr/local/cpanel/bin/setupdbmap : To recreate the dbusermap

# /scripts/update_db_cache : To recreate DB cache

Help with cPHulk Brute Force Protection !

Brute force is an attack that involves using an automated system to guess the password to your web server or services. cPHulk provides protection against brute force attacks.

Some useful commands to deal with cPHulk Brute Force Protection from the back-end :

First get access to the db cphulkd via mysql

#  mysql -u root -p

> use cphulkd

You can view the list of IPs which are blocked as per the brutes table :

> select * from brutes;

To select the IP’s alone and not any other data, use this :

> select IP, BRUTETIME from brutes order by BRUTETIME;

To delete the entire list of IPs in brutes :

> DELETE FROM brutes;

If you brutes lists is too large and you need to find if any particular IP is in the list, you can use this :

> SELECT * FROM `brutes` WHERE `IP`='x.x.x.x';

To delete that particular IP,

> DELETE FROM `brutes` WHERE `IP`='x.x.x.x';

To whitelist a particular IP,

# /scripts/cphulkdwhitelist IP

To disable/enable cPHulk :

# /usr/local/cpanel/bin/cphulk_pam_ctl --enable ( enable the service )
# /usr/local/cpanel/bin/cphulk_pam_ctl --disable ( disable the service )

You can also check the cphulk logs from

# /usr/local/cpanel/logs/cphulkd.log


Clearing huge eximstats db !

The eximstats database might tend to grow in size if there is high amount of mailing from your server.

Check if the following value from WHM is set to a higher interval :

Home »Server Configuration »Tweak Settings

>> “The interval, in days, to retain Exim stats in the database”

You might need to reduce the time interval to retain the eximstats.

Under usual situation, eximstats will grow huge in size when there is spamming carried out from your server. First check if your server is involved in spamming and if so, find the source of spamming and eradicate it.

You can remove the eximstats mysql db as follows :

# mysql -u root -p
# use eximstats
# delete from sends;
# delete from smtp;
# delete from failures;
# delete from defers;

If the above tends to consume lots of time, you can use the below commands to clear eximstats :

# mysqladmin drop eximstats

# mysqladmin create eximstats

# mysql eximstats < /usr/local/cpanel/etc/eximstats_db.sql


Migrate all accounts from a cPanel server to another one !

Yes, you have got the WHM option of migrating the accounts. However, most chances are for it to fail.

Also, you cannot keep your eyes on the screen and watch the progress. What if your local internet connection breaks in between this ? It ends up in a mess and more work for the Administrator.

So, its preferred to migrate your accounts from the back-end. Following set of commands and a small script will help you.

#  screen -S acttransfer ( Running the commands in a screen is always the safest option )
# ls /var/cpanel/users > fulllist.txt

# vi


#! /bin/bash
for i in `cat fulllist.txt`; do /scripts/pkgacct $i; done
scp -r /home/cpmove* root@server:/home

# chmod +x

# ./

You will have to manually type in the root password of the other server when scp prompts. More easy is to set up a key-based authentication so that you wont have to glance even.  Check here on setting up key-based authentication for your server.

On the destination server, you can use this one-liner to restore all the accounts ( Make sure you transfer/copy the file  ‘fulllist.txt ‘ to the destination server  )

# for i in `cat fulllist.txt`; do /scripts/restorepkg $i; done

Fix a broken Perl installation – cPanel

Please note that this guide is applicable for cPanel versions prior to 11.36 and does not fix the issues on cPanel 11.36 + versions.

When you have a broken Perl in your cPanel box, it becomes a big issue and it affects other services which depends on the Perl modules. Usually, you can fix the broken modules using the cPanel provided scripts such as /scripts/checkperlmodules or even a force cPanel update ( /scripts/upcp --force ) should do the job.

However, if you ever tried to install another version of Perl via yum or from the source,  other than cPanel, things will break. This would prevent even cP from updating and many other functions.

A usual workaround for this issue is to manually re-install Perl as provided by cPanel installers.


tar xzvf perl588installer.tar.gz
cd perl588installer/


If you still see issues and is not able to complete the above installation, you might need to manually install Perl from the source files.

Following would help you :

Get the version 5.8.7 from the official source,

You can use this direct link to download the file.

# Extract the folder and enter in

# sh Configure -de -Dusethreads

# make && make test && make install

# cd /usr/bin

# mv perl perl-backup

# ln -s /usr/local/bin/perl perl

# Re-install cPanel - /scripts/upcp --force


This would fix the issues with a broken Perl in pre-11.36 cPanel & WHM

A quite note on versions after 11.36 :

Since cPanel & WHM 11.36, when system perl (/usr/bin/perl) began being handled by CentOS/RHEL/CloudLinux and cPanel internal perl began being handled in /usr/local/cpanel/3rdparty/bin/perl (symlinking to the version cPanel provide), cPanel do not recommend using source installations for Perl.

CentOS 6 onward uses system perl 5.10 via rpm (yum reinstall perl is the way to fix system perl), and cPanel’s perl is also installed via rpm files with cpanel-perl* whatever as the names.

The way to fix internal cPanel perl would then be to remove the cpanel-perl rpms and to reinstall them using this script:

/scripts/fix_cpanel_rpms –fix

Again, system perl would be fixed using “yum reinstall perl

The cPanel perl for 11.46 and higher (11.48, 11.50) is 5.14:

root@server [~]# ls -lah /usr/local/cpanel/3rdparty/bin/perl
lrwxrwxrwx 1 root root 44 May 23 19:26 /usr/local/cpanel/3rdparty/bin/perl -> /usr/local/cpanel/3rdparty/perl/514/bin/perl*

root@server [~]# /usr/local/cpanel/3rdparty/bin/perl -v
This is perl 5, version 14, subversion 4 (v5.14.4) built for x86_64-linux-64int


csf/lfd — Not running nor able to restart ?

Has the firewall csf along with lfd crashed in your server ? When trying to restart the service, you might find the following error :

Starting lfd:

Error: You have an unresolved error when starting csf. You need to restart csf successfully before starting lfd (see /etc/csf/csf.error)
[ OK ]

– Check the file /etc/csf/csf.error to see if you can spot the error. If the file is empty, the service might have gotten too old.

Upgrade csf/lfd to the new version by running the following script :

# csf -u


Changing the Exim interface IP

In order to change the exim interface IP, do the following :

-SSH to your server and edit the file – /etc/mailips : This file controls the IP address from which each domains are allowed to send the mails. If the file is not present, create it. Open the file for editing using your preferred text editor. You will need to configure this file in the following way:

*: (<- desired IP )

^ the option * denotes the entire list of domains in the server. If you require just one domain to send from a different IP, specify the domain there instead of ‘*’

– Disable the following from WHM

From WHM »Service Configuration »Exim Configuration Manager>> Domain and IPs>> Send mail from account’s dedicated IP address "on"

– Enable this option,

Reference /etc/mailips for outgoing SMTP connections.

And now, restart the exim service.

/root/.cpanel/comet consuming huge disk space ?

On checking the disk usage of your server, you might notice that /root/.cpanel/comet consumes considerable amount of disk space.

This happens when high number of emails are in the mail queue manager which can occur when spamming is carried out in the server.

Manually purging the files would be an effort-consuming task.

Clear the comet directory by giving the following command via SSH:

# /usr/local/cpanel/bin/purge_dead_comet_files

Remove fantastico plugin from WHM !

SSH to the server and issue the following commands to remove fantastico :

# rm -rf /var/netenberg/
# rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/
# rm -rf /usr/local/cpanel/3rdparty/fantastico*
# rm -rf /usr/local/cpanel/base/frontend/*/fantastico
# rm /usr/local/cpanel/base/frontend/x/cells/fantastico.html
# rm /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico.cgi

After removing fantastico from the server, does any of the cPanel accounts show the fantastico icon ?

-You can remove it by doing the following :

From the backend, go to /var/cpanel/registered_cpanelplugins
and delete the file “Fantastico_De_Luxe”

Then, from WHM->Packages->Feature Manager, remove the fantastico check box.

Memory drain issues on MySQL 5.6 ?

With the recent upgrade of WHM/cPanel, the users get the ability to upgrade their MySQL server to 5.6.x ( x > 6 ).

However, when this upgrade is done, lot of server owners are seeing memory drainage issues. An idle MySQL server tends to consume around 50% of your RAM, which is a very serious concern.  I had to upgrade a personal server of mine and faced serious issues with memory drainage. A more dig on this issue, highlighted a change brought around in the latest versions of MySQL with the parameter ‘performance_schema‘.

Starting from MySQL 5.6.6, this parameter performance_schema is enabled by default and it consumes the server memory even at an idle state. Performance Schema automatically sizes the values of several of its parameters at server start-up if they are not set explicitly, which causes the memory usage to spike up.

The workaround for this issue is to disable performance_schema. This can be done by adding the following value to the configuration file – my.cnf

performance_schema = 0

Add this line and restart MySQL server. Things should be fine from now 🙂

Note : When you try to upgrade MySQL to 5.6.x, from a VPS with 1GB of RAM provisioned you will need to edit the config file and pass the keyword to disable performance_schema ( Yes, before the upgrade ). If not, there are chances for your upgrade to fail partly, due to MySQL upgrade script installing MySQL server components each and it gets killed due to over-usage of RAM as performance_schema is enabled by default.