cPanel restorepkg bug in version 11.42.1 affected to cpremote restore

The release version  of cpanel seems to be  having a bug  for restoring backup accounts. It is only  restoring the tar account .  It failing to restore from a backup location ( extracted tar file ) . This will be updated in cPanel forum too

Steps to Recreate  The issue :

1) Take the backup of user foo,

# /scripts/pkgacct foo

2) Extract it to /home

# cd /home
# tar -xzf cpmove-foo.tar.gz
# rm -f cpmove-foo.tar.gz

3) Now restore it using the following ,

# /scripts/restorepkg --force /home/cpmove-foo

It show the following errors ,

# /scripts/restorepkg --force --user /home/cpmove-foo
Using pre-extracted cpmove file
cPanel restorepkg 2
cPanel user: foo
Force Mode: yes
Reseller Privs Restore: yes

Found /home/cpmove-foo !

cpmove- prefix is missing, but non prefixed directory exists.. the cpmove- prefix discarded.

Extracting Domain....Done
Sorry, we were unable to restore the account. Information about inhouse's primary domain is either missing or corrupt. For more information, please examine /home/cprestore/foo/cp/foo

So it is failing to restore from this path. Looks like only tar files are restoring .

We reported this bug to the cPanel and their support confirm it . So they assigned it  to their internal department with case id #97497  . We hope the cPanel developers fix this issue soon.

This bug also affected the restore procedure of cPremote too with the full account restore option, because the cpremote use cpanel restorepkg feature itself for restoring the accounts.  So  you may please use the following workaround for restoring cpanel or cpremote backups.

1) make a tar file of  your cpanel backup folder , let us say the account name is  foo ,. then create a tar as follows,

# tar -cf foo.tar  foo/

2) Upload this tar file to  /home
3)  Restore the  backup using  the following command,

# /scripts/restorepkg /home/cpmove-foo.tar

We will update again after getting a reply from the cPanel development team.

How to Check and Fix OpenSSL Heartbleed bug in cPanel/WHM servers

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library.Essentially this means you probably need to regenerate the private keys used to create your SSL certificates, and have them reissued by your certificate authority.This is not a difficult task but does take some time to get OpenSSL updated across all your servers, then go through the process to generate, reissue and install certificates across all locations they are deployed.

The bug is not present in 1.0.1g, nor is it present in the 1.0.0 branch nor the 0.9.8 branch of OpenSSL some sources report 1.0.2-beta is also affected by this bug at the time of writing, however it is a beta product and I would really recommend not to use beta quality releases for something as fundamentally important as OpenSSL in production.

Status of different versions:

Vulnerable OpenSSL versions:
  • OpenSSL 1.0.1 vulnerable
  • OpenSSL 1.0.1a vulnerable
  • OpenSSL 1.0.1b vulnerable
  • OpenSSL 1.0.1c vulnerable
  • OpenSSL 1.0.1d vulnerable
  • OpenSSL 1.0.1e vulnerable
  • OpenSSL 1.0.1f vulnerable

through 1.0.1f (inclusive) are vulnerable.

NOT Vulnerable versions:
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable

CentOS / Redhat release has already published the new patched version of OpenSSL1.0.1. Please check

How to check Heartbleed Bug:

You can check Heartbleed bug by using the following sites:

Make sure every thing is reported okay.

How to FIX OpenSSL Vulnerability

The patched OpenSSL 1.0.1 RPM has already been published to the RHEL 6 and CentOS 6 repositories, so the only steps that should be necessary to update these servers are to run “yum update” to install the updated version of OpenSSL and then either fully restart all SSL-enabled services, including sshd, or reboot the server. I recommend rebooting the server so that no services are missed, and it also gives you the opportunity to install an updated kernel if one is available.

So if your system is prone to this vulnerability or reported as vulnerable from above sites then you may please proceed with the following steps:

# yum update

Make sure you have the updated OpenSSL packages are installed, then try to rebuild your server software’s using:

# /scripts/easyapache

Make sure the newly installed OpenSSL version include patched CVEs (Common Vulnerabilities and Exposures).

# rpm -qa | grep openssl

Output Should look like:

# rpm -qa | grep openssl
# rpm -q --changelog openssl-1.0.1e | grep -B 1 CVE-2014-0160

Output Should look like:

# rpm -q --changelog openssl-1.0.1e | grep -B 1 CVE-2014-0160
* Mon Apr 07 2014 Tomáš Mráz <> 1.0.1e-16.7
- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension

Restart all services like cPanel ,SSHD ,HTTPD ,Dovecot ,Pure-Ftpd ,MySQL and any other services that are using SSL libraries.I recommend rebooting the server so that no services are missed.

If your server is RHEL 5/Centos 5 then OpenSSL does not have the bug and its version would be something like openssl-0.9.8e. So CentOS/RHEL 5 users are safe from this vulnerability.

How To Install PHP 5.2 on cPanel/WHM 11.40+

cPanel, Inc. has released EasyApache 3.24. This version removes Apache 1.3/2.0, PHP 5.2, and mod_frontpage. As mentioned in
Introducing EasyApachea Optimal Profiles, These End of Life (EOL) items are no longer available in EasyApache.

These items have been removed for the following reasons:

  • They are no longer supported by their respective developers.
  • They include unpatched CVEs (Common Vulnerabilities and Exposures).
  • EasyApache provides the most up-to-date, supported versions of Apache (2.2/2.4) and PHP (5.4/5.5).

Keep in mind that viable alternatives to mod_frontpage exist, such as WebDAV and FTP. Also, PHP 5.2 and mod_frontpage are available as custom modules (“opt mods”).

You can read more about how to use and install Custom Modules at :

Downgrading PHP version is not a good idea.We always suggest you to use latest updates version of software/Scripts you are using.In new cPanel version they have completely dropped support for PHP version 5.2 .If you PHP is corrupted or need to recompile it for some reason then you can’t rebuild your old PHP version using EasyApache (3.24) .So you may have to do it at custom.You can do this by following the steps given below.

Install Dependencies using ‘YUM’

# yum install libcurl-devel libmcrypt libmcrypt-devel aspell aspell-devel tidy libtidy libtidy-devel libxslt libxslt-devel 

# cd /var/cpanel/easy/apache/custom_opt_mods/

# wget

# tar -C /var/cpanel/easy/apache/custom_opt_mods -xzf custom_opt_mod-PHP5217.tar.gz

# nano /var/cpanel/easy/apache/rawopts/all_php5



You can enable all relevant PHP modules in “/var/cpanel/easy/apache/rawopts/all_php5”.

Then recompile Apache using “/scripts/easyapache”. Go to step 3 “Please choose which specific PHP version(s) to build”
If you want no PHP except 5.2 then on the “PHP Version” screen chose “None” and continue to step 4, The “Short Options List” page you will see “PHP 5.2.17 support (no FastCGI)” listed. Check that box and continue your EasyApache like normal.

After EasyApache you can re-install IonCubeLoader and Zendopt using :

# /scripts/phpextensionmgr install IonCubeLoader
# /scripts/phpextensionmgr install Zendopt

You can install the following PHP extensions using script ‘/scripts/phpextensionmgr’

  • EAccelerator
  • IonCubeLoader
  • Zendopt
  • Xcache
  • SourceGuardian
  • PHPSuHosin

If necessary you can install other missing PHP modules without doing Easyapache.You can do this simply by login into the server as root :

# cd /home/cpeasyapache/src/php-5.2.17/ext/mcrypt/  (Go to particular extension folder,Here I need to install Mcrypt)

# phpize
# ./configure
# make
# make install

After that you can see extension directory path:

# php -i | grep extension_dir

# ls -al  /usr/local/lib/php/extensions/no-debug-non-zts-20060613/
# vi /usr/local/lib/php.ini

add extension=”” .Then restart apache using :

# /etc/init.d/httpd restart

Other method is:

# wget -O /usr/local/src/tidy-1.2.tgz
# cd /usr/local/src/
# tar zxvf tidy-1.2.tgz
# cd tidy-1.2
# phpize
# ./configure
# make
# make install
# php -i | grep extension_dir
# ls -al  /usr/local/lib/php/extensions/no-debug-non-zts-20060613/
# vi /usr/local/lib/php.ini

add extension=”” extension under your extension directory path and restart apache using:

# /etc/init.d/httpd restart

That’s it !

How to Safely Change the Location of MySQL Data Directory on cPanel/WHM Servers

I had seen many cPanel servers running out of disk space due to MySQL data directory on “/var” partition.To solve this issue you need to move your MySQL data directory to a new location.There are also other situations like moving your MySQL data’s to a new standalone database server or moving it to a separate solid-state-drive partition for increasing MySQL server performance.Whatever the reason, moving MySQL data directory is simple and has no impact on cPanel functionality.

In this article I am moving MySQL data directory to “/home” partition.You can proceed with the following steps for moving MySQL data directory:

1.Create a backup

Please make full database backup(including system tables) before moving your data directory. This action will prevent data losing in case if something goes wrong.

# tar -cvf mysql.tar /var/lib/mysql

2.Edit the my.cnf file

# vi /etc/my.cnf

Now in the mysqld section add the following. Don’t restart MySQL after adding new entry.


3.Create the new MySQL data directory

# mkdir /home/mysql

4.Now migrate the data to the new location using rsync command.

# nohup rsync -avp /var/lib/mysql/ /home/mysql

The nohup will keep rsync running even when your session with the server end, the other part “

# tail -f nohup.out

Notice that you have to do the syncing process twice , because when moving large size of data can take some time to complete and the tables may have changed in between. When we run it the second time we hopefully get it so that when the switch over happens there is very little, if any, lost data. If you can afford the downtime simply shut down MySQL before running this command.If you cannot though running it twice then quickly copy/pasting the other commands is a valid substitute.

5.Typically you want to stop MySQL for syncing data completely.

# /etc/init.d/mysqld stop

6.Start the re-sync process once again to copy data’s completely.

# rsync -avp --delete /var/lib/mysql/ /home/mysql/

7. Change ownership of new created MySQL data directory to MySQL.

# chown -R mysql:mysql /home/mysql/

8. Now, re-link the socket file to /tmp:

# rm -rf /tmp/mysql.sock
# ln -sf /home/mysql/mysql.sock /tmp/mysql.sock

9. Since you already added the data directory entry to my.cnf , all you need to do is restart again and everything should be working.

# /etc/init.d/mysqld start

Check whether your MySQL logs are written at the new location (Eg: /home/mysql/hostname.err)

10. Create a sample database named “foo” for checking.

# mysqladmin create foo

11. Check whether new database is created at new data directory.

# ls -d /home/mysql/foo

12. After confirming every thing works properly.You can remove the old data directory.

# rm -rf  /var/lib/mysql

That’s it !