How do I upgrade Apache on my Cpanel box?

There are two ways to update your Apache version on cpanel.

The first is from within WHM. Underneath the “Software” section in the menubar is “Apache Update.” Click this link and then follow the on screen directions.

The second option is from the command line. Run “/scripts/easyapache”, which will provide an update interface including a few more options than WHM.

It is highly recommended that you create a backup of your Apache configuration before preforming an update to a newer version.

WHM locked out – cphulkd

cPHulk Brute Force Protection prevents malicious forces from trying to access your server’s services by guessing the login password for that service. BUT sometimes it becomes troublesome when you are accessing the cPanel with incorrect password and cPanel assuming you as attacker blocks you with below message :

This account is currently locked out because a brute force attempt was detected. Please wait 10 minutes and try again. Attempting to login again will only increase this delay. If you frequently experience this problem, we recommend having your username changed to something less generic.

To get out of such situation you can disable cphulkd protection :

login via ssh and disable cphulkd using the command below.

# /usr/local/cpanel/bin/cphulk_pam_ctl –disable

This should allow you to login to WHM and double check your cphulk settings.

You can view IP addresses that have been blocked via the WHM interface: WHM -> Security -> Security Center -> cPHulk Brute Force Protection in the Brutes table. On that screen, you can also customize brute force protection settings.

Flush DB will remove all blocked IPs:

WHM >>  Security Center >> cPHulk Brute Force Protection >> Click on Flush DB

Well the other way to this is to remove the IP’s blocked by cPHulk from its database .

ssh to the server login as root and type the following at the prompt

[root@server:] mysql

mysql> use cphulkd;

mysql>BACKUP TABLE  brutes TO ‘/path/to/backup/directory’;

mysql> SELECT * FROM brutes WHERE `IP`=’’;

mysql> DELETE FROM brutes WHERE `IP`=’’;



cPanel : WARNING: RVSiteBuilder recommend PHP maximum execution

RVSiteBuilder warning messages under WHM :

WARNING: RVSiteBuilder recommend PHP maximum execution time of each script , in 180 seconds or above.
HELP: Edit /usr/local/cpanel/3rdparty/etc/php.ini and change “max_execution_time=180” or above, and restart cPanel service (/usr/local/cpanel/startup).

WARNING: RVSiteBuilder recommend maximum size of POST data 105M or above.
HELP: Edit /usr/local/cpanel/3rdparty/etc/php.ini and change “post_max_size=105M” or above, and restart cPanel service (/usr/local/cpanel/startup).

WARNING: RVSiteBuilder recommend maximum allowed size for uploaded files that PHP will accept 100M or above.
HELP: Edit /usr/local/cpanel/3rdparty/etc/php.ini and change “upload_max_filesize=100M” or above, and restart cPanel service (/usr/local/cpanel/startup).

Solution :

Execute using root logins :

perl /var/cpanel/rvglobalsoft/rvsitebuilder/panelmenus/cpanel/scripts/

Restart cPanel :


If again you see the warnings after cPanel restart, manually change the values for PHP under WHM >> Tweak Settings.

PHP max execution time for cPanel PHP execution in seconds (default 90)
PHP Max Post Size for cPanel PHP in Megabytes (default 55M)
cPanel PHP Register Globals (Off [unchecked] is recommended for security reasons)
PHP Max Upload Size for cPanel PHP in Megabytes (default 50M)
Loader to use for internal cPanel PHP (Use oldsourceguardian for version 1.x and 2.x)




This fixes your issue.

Assigning Name server IPs manually via SSH – cPanel

Currently cPanel will start with eth0 and work through eth1 when you assign nameservers to your IPs via WHM. Unfortunately, this will automatically choose your management IP range first, which of course are non-routable. There are two work-arounds for this:

1: Create a fake nameserver record on your private IPs, and add an A record for that nameserver to your DNS. This is the fastest option, but not the best.

2: SSH to your server and edit /etc/nameserverips manually. An example file is blelow:


Just replace the ‘0’ after the ‘=’ with your nameserver name. In this example, the first IP (10.x.x.x) is the management IP, and not used for nameservers. The next two IPs are public and assigned to two nameservers. The last three are public and not in use.

How can I compress my CPanel domlogs log files?

Before setting up compression of your logs you will want to have cpanel run the stats as often as possible. This is so you do not miss any stats that would have been included were your logs not compressed before stats run.

To do this, login to WHM, and click on Tweak Settings under Server Configuration in the left menu. Scroll down to Stats and Logs, and then in the field next to “Number of days between processing log files and bandwidth usage (default 1, decimal values are ok):” enter ‘.5’.

This will cause your logs to be run twice a day, and should allow you to have up to date stats.

After doing this, we can begin to setup your domlogs compression. You will need to open an ssh shell to your server to complete this.

Change directories to /etc/logrotate.d/ and find the file named httpd. You will need to copy this file to a new file in the same directory:

root@cpdemo [/etc/logrotate.d]# cp httpd domlogs
root@cpdemo [/etc/logrotate.d]# ls -la domlogs
-rw-r–r– 1 root root 390 Nov 8 21:26 domlogs
root@cpdemo [/etc/logrotate.d]#

Now you will want to edit your new file to contain the following:

/usr/local/apache/logs/*.com /usr/local/apache/logs/*.org /usr/local/apache/logs/*.net {
rotate 2
/bin/kill -HUP `cat /usr/local/apache/logs/ 2>/dev/null` 2> /dev/null || true

Just save your new file and you are done. Most linux distributions come default with a logrotate cronjob running nightly that will work with this configuration.

cPanel required ports list

Cpanel required ports list

53DNStcp/udpinbound/outbound Inbound only needed if you run your own DNS server
465smtptcp/ssl, tcp/udpinbound/outbound
993imap4ssl tcpinbound
995pop3ssl tcpinbound
2083cpanelssl tcpinbound
2087whm ssltcpinbound
2089cp licensetcpoutbound
2096webmailssl tcpinbound
3306mysqltcpinboundOnly if you need to connect remotely

WHM shows all accounts as 0/unlimited quotas

There are many possible causes of this issue, however most relate to quotas being enabled on the filesystem itself.
Some ways to check the most common errors are:

Quotas enabled in the filesysem

By default, quoatas are enabled in the kernel on all SoftLayer Linux and FreeBSD kernels. If you’ve compiled/installed your own kernel, you’ll need to verify that quotas are enabled.

— FreeBSD systems will need to add “options QUOTA” to their kernel configuration and recompile. They will then need to add “enable_quotas=”YES”” to their /etc/rc.conf file.

— To enable quotas on a certain partition, one will need to modify the /etc/fstab file by adding usrquota (or grpquota if one desires the quota to pertain to an entire group rather than an individual user) to the options column (e.g. “LABEL=/home /home ext3 defaults,usrquota 0 0”).

[root@linux-test-server ~]# cat /etc/fstab
# This file is edited by fstab-sync – see ‘man fstab-sync’ for details
LABEL=/                 /                       ext3    defaults,usrquota        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
LABEL=SWAP-sda2         swap                    swap    pri=0,defaults        0 0
/usr/tmpDSK             /tmp                    ext3    defaults,noauto        0 0
/tmp             /var/tmp                    ext3    defaults,bind,noauto        0 0
[root@linux-test-server ~]#

— Once those entries are added, a reboot of the server should resolve the issue.

Run /scripts/fixquotas

Cpanel has it’s own tools to repair the quotas for it’s accounts. the command
run through ssh may resolve the issue.


The command
#repquota -ua
will tell you if quotas are being reported for OS users at all.


The command
#quotacheck -fv /home
will display the quotas for that filesystem, however the partition has to be unmounted first. It’s best to do this from Single User mode.

“IMPORTANT: do not ignore this email: The hostname resolves to . It should resolve to X.X.X.X”

A newly setup cPanel system may have a message such as the following show the first time that you login to WHM.

IMPORTANT: Do not ignore this email.
The hostname ( resolves to . It should resolve to xx.xx.xx.xx. Please be sure to correct /etc/hosts as well as the 'A' entry in zone file for the domain.

Some are all of these problems can be caused by
/etc/resolv.conf being setup incorrectly. Please check this file if you
believe everything else is correct.

You may be able to automaticly correct this problem by using the 
'Add an A entry for your hostname' under 'Dns Functions' 
in your Web Host Manager

Here are the steps that you should work through to solve this issue.

  1. Follow the instructions that cPanel has provided by checking to see if you can solve this issue using WHM provided tools. Login to your server’s WHM (not cPanel) by going to https://[YOUR SERVER IP]:2087 in your web browser.
  2. You probably see the error now, go ahead and close it for now and scroll down the left hand Functions Menu until you find the heading ‘DNS Functions’. Click on ‘Add an A entry for your hostname’. WHM will try to analyze your hostname and then present you with a button to click that says Add the entry, go ahead and click on that. WHM should automatically try to add the relevant A record for your hostname to the DNS zone present on your system.
  3. Go ahead and logout and then log back in to WHM to see if the message returns. Look to the top of WHM to see the “Logout(root)” link. Optional Tip: If you don’t like logging into and then out of WHM while testing the fixes you can instead login to your server via SSH and whenever you are ready to test simply run the following command:
    root@myserver [~]# /scripts/ipcheck

    This command will send you an email immediately if your settings are still incorrect.

  4. Hopefully that worked, but if not, we should go ahead and edit your /etc/hosts file just in case. Login to your system via SSH. Use your favorite text editor to make sure that your /etc/hosts file looks something like this.
    root@myserver [~]# cat /etc/hosts              localhost
    xx.xx.xx.xx   myserver

    If you would like more information on the structure of the hosts file type ‘man hosts’ as the structure of this file is outside of the scope of this document.

  5. Use your preferred method of checking for the message again. Has it returned? Are you sure that your server is using the proper resolvers? Make sure that your /etc/resolv.conf has the correct resolvers. Contact your server provider for the correct resolvers. People who are on Softlayers network can use :
  6. If you are using SoftLayer’s name servers then login to our Portal and go to Public Network > dns and click to edit the domain in question. Simpy add an A record with your server’s main IP Address into the fields.If you are using some other name servers, you will need to contact the Administrator of that system to ask how you may add additional DNS Records.

Securing the TMP Partition and Tracking Hacks

Are your temp partitions putting out behind your back? Anyone who’s ever administered a Linux server would know the risk of leaving the /tmp directory unsecured, moreso on a webserver that is shared among multiple websites.

The tmp directory is world-writeable and used by a majority of services on a machine — including the storage of PHP and MySQL session files. One issue that I’ve seen on older servers is that one customer’s poorly-coded website would get exploited and end up downloading a file into the /tmp directory, then have that hack file executed on the server as a nobody-owned process. Hack processes are the easiest to find, as they always have a little something extra.

This should go without saying, but hack processes can run from almost anywhere, not just /tmp. I’m mainly bringing up the tmp directory because it’s the most targeted location for hack files if it isn’t secured properly.

Identifying Hack Processes

To start out, log into your server as root as issue the following command to see all the nobody-owned processes running on the machine. This is assuming that Apache on your webserver runs as ‘nobody’:

root@localhost[~] ps -efw |grep nobody |more

A majority of the output will reflect legitimate Apache processes:

nobody 8748 25841 0 21:35 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 8785 25841 0 21:35 ? 00:00:01 /usr/local/apache/bin/httpd -DSSL
nobody 8988 25841 0 21:36 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL

You’ll see that they all have the same parent process ID of ‘25841′ and all of the commands look about the same. However, you may see something that looks like this:

nobody 15707 26407 0 11:18 ? 00:00:00 [sh <defunct>]
nobody 15717 1 0 11:18 ? 00:00:04 /usr/bin/perl
nobody 13016 1 0 14:14 ? 00:00:00 /usr/bin/perl

nobody 8988 1 0 21:36 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL -d3

All of these are hack processes. A few things to look for:

– Perl and shell (sh) processes on most systems run as the user that is executing them, not ‘nobody’. If this is true on your system, a nobody-owned perl process is probably a hack

– The parent ID of the process is different than all the others of the same service — these can be easily faked

– For Apache, an extra little switch on the end of the command (../httpd -DSSL -d3) – ‘d3′ is usually the name of the hack file that is being executed through Apache (not always).

Now I know you probably have the urge to kill -9 it, but don’t. Killing a hack process before determining what it is or where it came from is only going to let it happen again.

Tracking the process:

Once you know which processes should not be running, you need to know where they came from. The *easiest* way to track a process is through the lsof command. If you take the process ID (not the parent) and run an lsof it will tell you everything you want to know:

lsof -p 8748

From here I can see that this process is running from a folder in a user’s account. All I need to do now is kill it off, then remove the hack files from that user’s directory and let them know to update their shit.

TMP Directory Hacks

I’ve seen my fair share, but many hack processes will be spawned from the temp partitions of the server (like /tmp, /tmpDIR, /dev/shm), as these are usually set to 777 to allow programs to store their temporary files. When you first look in your TMP directory you’re going to see a lot of stuff — this is normal, but you’ll want to look for nobody-owned files that stand out. Just a hint, some hacks will try to trick you with their names. I have seen many that are named “…” or “httpd” to make them look legitimate, but I know that httpd (the service that runs Apache) should not be in the tmp directory…and that’s what makes it stand out.

Securing the tmp Partition

I’m not going to go too far into this here, because there’s already a very good website with this information available.

If you are on a cPanel server, you should run /scripts/securetmp in addition to following the instructions above.