“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 (hostname.server.com) 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
    127.0.0.1              localhost
    xx.xx.xx.xx            myserver.mydomain.com 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 :
    nameserver 10.0.80.11
    nameserver 10.0.80.12
    
  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.

Error 550 – “The recipient cannot be verified” – cPanel

On servers running cPanel, you may find that mail sent to valid users it bounced back by your mail server. The bounce back messages will be similar to the following.

PERM_FAILURE: SMTP Error (state 9): 550-"The recipient cannot be verified. 
Please check all recipients of this550 message to verify they are valid.
If this is occurring, you will need to check your exim_mainlog file for entries 
similar to the following.
H=(nf-out-0910.google.com) [IP] F=<[email protected]> rejected RCPT 
<emailAccount@domainName>: No Such User Here
If you are sure that email account does indeed exist, you will need to run the 
following commands to correct the issue.
/scripts/updateuserdomains
/scripts/mailperm 
You will then also need to check your /etc/localdomains file and verify that the 
domain name is present. Also verify that the DNS line in your 
/var/cpanel/user/username contains the domain as well.

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.

Installing IonCube loader with Zend Optimizer – cPanel

This is a common request we get for Ioncube to be installed. It’s generally not an issue, but when you factor in other optimization plugins like Zend and eAccelerator, a common misconception is that the three don’t get along. It’s very easy to install Ioncube into a PHP installation that already has Zend and eAccelerator.

This tutorial is specific to cPanel, assuming that you are using php 5.2.x with Zend 3.x.x.

If you need help installing eAccelerator, you can see this tutorial. For help with installing Zend, you can go here. The versions in both these tutorials are outdated, so you’ll probably want to apply the instructions to the newest versions available.
Go to http://www.ioncube.com/loader_download.php and pick your download. This example assumes that you are using php 5.2.

cd /usr/src
wget http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86.tar.gz
tar -xvzf ioncube_loaders_lin_x86.tar.gz
cd ioncube

Copy the loader config to the user’s public_html or another location where you can access it from a browser.

cp ioncube-loader-helper.php /home/username/public_html

Now in your browser go to the loader file that you just copied. This file will tell you exactly which extension you need to use. Choose the ‘php.ini Installation Instructions’ link, and you should see something like this after the php config output:

zend_extension = /<path>/ioncube_loader_lin_5.2.so

Move the ioncube directory to a more permanent location:

mv /usr/src/ioncube /usr/local
chown -Rf root:root /usr/local/ioncube

Edit the php.ini and add look for this section (may not be exact):

[Zend]
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.0.1
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.0.1
zend_optimizer.version=3.0.1
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

Above this section, add this line:

zend_extension=/usr/local/ioncube/ioncube_loader_lin_5.2.so

Of course, make sure that the .so file is the one that the loader helper told you to use! After that is added, STOP and then START Apache to make sure that it’s loading. You should now see IonCube in your phpinfo file.

If you’re using eAccelerator, you shouldn’t need to change the location of the plugin loader in your php.ini.

Note that if Apache doesn’t start, it’s probably because of the order in which you have Zend and ioncube loading.  The lines for Ioncube should be above those for Zend optimizer.

Lastly, you should test your IonCube installation to make sure that it can decode its own files. In the original ‘ioncube’ directory that you moved, there’s a test ‘ioncube-encoded-file.php’ file that you can load through a browser to make sure that it works.

How to Upgrade PHP – cPanel

Whether you compiled manually or with EasyApache, running a PHP upgrade from a previous version is super easy but also one of the most common questions I get. There are 3 likely assumptions about your current environment (specific to Linux servers, sorry Windows users):

1. You are running a cPanel server and have PHP compiled by EasyApache

2. You compiled PHP manually from source

3. You used Yum, Aptitude, or another package manager

EasyApache

Perhaps the easiest (but least efficient time-wise), simply log into WebHost Manager > Apache Update and select “Previously Saved Config” option and “Start Customizing Based on Profile“. The next screen should take you to the Apache version, which you can keep the same or upgrade as well. Then you’ll be taken to select either PHP 4 or PHP 5, proceeded by the actual version you wish to run and then the options for both Apache and PHP on the next two steps (Advanced Configuration). You usually do not need to change the options if your target is just a simple upgrade within the same version family, but if you changed the Apache version, updated cPanel recently, or are upgrading to a different PHP version family (like 4.4.7 to 5.2.x), then you’ll want to double-check the Apache/PHP build options to make sure they are what they need to be before selecting “Save and Build.” If you are running older versions of EasyApache (usually with cPanel 10 or early versions of cPanel 11 STABLE) then all you have to do is select ‘Load Previous Config‘, pick your PHP version, and ‘Build‘.

Source

If you’ve compiled PHP from source (./configure && make && make install method), you can use your previous configure arguments to compile against a different version. Refer to your server’s phpinfo file (if you don’t have one just create a PHP script with <?php phpinfo(); ?>) and copy the entire ./configure statement into notepad and remove the single quotes. Once you’ve done this, download the source tarball of the new PHP version, untar, and then enter the installation directory. From there, all you have to do is paste the configure statement from notepad. For instance, for PHP 5.2.5:

wget http://www.php.net/get/php-5.2.5.tar.gz/from/this/mirror

tar -xvzf php-5.2.5.tar.gz

cd php 5.2.5

./configure –options-from-your-phpinfo

After the configuration is complete, the script may indicate at the end of its output that you’ve specified configuration options that do not exist. This usually will not affect your build, but you’ll want to review them and consult the PHP documentation on the correct syntax or alternatives to the invalid build options, as these can change depending on which version of PHP you are installing. Doing a ./configure –help will also display the valid options you can use.

Once you have a good configuration, you can go ahead with the make and make install to install the new version of PHP. If you have PHP integrated with Apache (usually you would unless you compiled as CGI) then the installation should have already updated the PHP binary for Apache and module loader in httpd.conf. However, you may need to manually comment out old module loaders if there are conflicts. You’re looking for something like this:

LoadModule php5_module        modules/libphp5.so

Package Installation

Some people have PHP installed via package manager, like Yum or Aptitude. Since the package software usually handles all aspects of the configuration and installation (outside of modules you may have installed via PEAR or Pecl), then you can use its update function to take care of the upgrade as well. Most have a specific option for upgrades, for instance Yum uses:

yum update php

For more information, see NixCraft’s article on PHP installations with Yum.

Fixing Common Perl Issues – cPanel

Sometimes you’ll notice that a certain function of cPanel or WHM was working fine, now all of a sudden you’re getting results that you’ve never seen before. Believe it or not, many problems with cPanel functionality related to processes running off of scripts is because of a perl corruption. To resolve this, usually the first step you should take is running a cPanel update, as this will correct most issues. If the problem persists, you may need to recompile perl from it’s core.

Before we start, here are a few of the most common indicators that there is a perl issue on your server:

  • Accounts are not created properly, like missing files
  • Frontpage extensions refuse to be installed
  • Stats won’t run, result in cryptic perl errors
  • Error messages that look like this:
(internal death) Sat Jun 3 21:01:55 2006 [32719] error: List::Util object version 1.14 does not match
 bootstrap parameter 1.18 at /usr/lib/perl5/5.8.7/i686-linux/XSLoader.pm line 92.
==> Starting cpbandwd (bandwidth monitoring for IMAP/POP)
Can't locate Class/Std.pm in @INC (@INC contains: /usr/local/cpanel /usr/lib/perl5/5.8.7/i686-linux
/usr/lib/perl5/5.8.7
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.7/Unix/PID.pm line 8.
Compilation failed in require at /usr/local/cpanel/bin/cpbandwd line 15.
BEGIN failed--compilation aborted at /usr/local/cpanel/bin/cpbandwd line 15.

In some cases, the error is specific about a perl module missing. If this is the case, look for the perlmod format in the error message. In the above example you can see ‘List::Util’ being referenced, so you can try to reinstall that either manually or from WHM:

/scripts/perlinstaller –force List::Util

If reinstalling the perl module itself does not solve the problem, you can recompile perl. First, do a perl -v from command line to see what version you are running. Then follow these steps:

wget http://layer1.cpanel.net/perl587installer.tar.gz
tar xvzf perl587installer.tar.gz
cd perl587installer
./install

/usr/local/cpanel/bin/checkperlmodules

If you are running 5.8.8, use the installer from:

http://layer1.cpanel.net/perl588installer.tar.gz

The recompile may take as long as 20 minutes to complete.

Downgrading MySQL to 4.x – cPanel

If you’ve upgraded MySQL via WebHost manager, the downgrade process is slightly more complex than the upgrade. This tutorial mainly covers a downgrade from 4.1 to 4.0, but also applies to downgrading from 5.x to 4.x.

*Back up all databases before proceeding, as all existing databases will be deleted!

1. Uninstall existing MySQL packages:

rpm -qa | grep -i mysql-

This should return a list of several rpm’s installed. You will need to remove them all with the rpm -e command .

2. Delete the active MySQL directory:

rm -Rfv /var/lib/mysql

3. Get cPanel Ready

Edit /var/cpanel/cpanel.config and change the version to the one that you are downgrading to (4.0, 4.1, etc)

mysql-version=4.0

Make sure that MySQL updates aren’t being skipped:

rm /etc/mysqldisable
rm /etc/mysqlupdisable

4. Install MySQL:

/scripts/mysqlup –force

5. Update the perl module:

/scripts/perlinstaller –force Bundle::DBD::mysql

Finally, recompile Apache and PHP via Web Host Manager.

Disabling SMTP Tweak – cPanel

The SMTP tweak will prevent users from bypassing the mail server to send mail (this is a common practice used by spammers). It will only allow the MTA (mail transport agent), mailman, and root to connect to remote SMTP servers.  In order words, users will need to use ‘localhost’ as their SMTP server for local mailing scripts to sent mail (source).  SMTP Tweak can be enabled or disabled in the ‘Security Center’ of WHM, or from command line using:

/scripts/smtpmailgidonly on|off

Upgrading phpMyAdmin – cPanel

The phpMyAdmin version is usually automatically upgraded when you run a cPanel update to a newer version. However, if you’re not quite ready to upgrade cPanel, you easily install a newer version of phpMyAdmin. Please be aware that future cPanel updates will overwrite your manual installation.

You will need to go to the phpMyAdmin download page and pick your version. This tutorial is specific to version 2.11, but should work for any:

cd /usr/local/cpanel/base/3rdparty
mv phpMyAdmin hold_phpmyadmin

wget http://prdownloads.sourceforge.net/phpmyadmin/phpMyAdmin-2.11.2.2-english.tar.gz?download

tar -xvzf phpMyAdmin-2.11.2.2-english.tar.gz
mv phpMyAdmin-2.11.2.2-english phpMyAdmin
cp hold_phpmyadmin/config.inc.php phpMyAdmin/
chown -R cpanel:cpanel phpMyAdmin

Then load up phpMyAdmin from cPanel or WHM and you should see the new version

Installing PostgreSQL – cPanel

Run the install script from command line

/scripts/installpostgres

Now in WHM under SQL Services locate Postgres Config and do an Install Config. You can also set the root password from here, but this password should only be alphanumeric.
PostgreSQL is installed now, but PHP is not compiled for it, so you’ll need to recompile PHP/Apache with postgreSQL support. You can do this manually, or through WHM. If doing so manually, here is the configure switch:

–with-pgsql=/usr

In your feature manager in cPanel, check the boxes for PostgreSQL and phpPgAdmin to enable them in your users’ cPanels.

ow when you log into cPanel you’ll see a section for PostgreSQL and phpPgAdmin which is the database management tool for Postgres.