How to fix cPanel Roundcube : An error occurred! Could not save the contact address

We came across the issue where a cPanel user logged into Roundcube webmail and was unable to add a contact to address book.

The specific error that Roundcube output on the screen was “An error occurred! Could not save the contact address.” which meant Roundcube had to have something other than a web error as everything else worked perfectly fine.

Well turns out it was actually a database error that I believe was caused due to a recent automatic upgrade when cPanel ran the normal cron runs.

Roundcube Error :
Recently I came across the issue where a cPanel user logged into Roundcube webmail and was unable to add a contact to address book.

The specific error that Roundcube output on the screen was “An error occurred! Could not save the contact address.” which meant Roundcube had to have something other than a web error as everything else worked perfectly fine.

Well turns out it was actually a database error that I believe was caused due to a recent automatic upgrade when cPanel ran the normal cron runs.

Force Upgrade :

First step I took was to attempt and force cPanel to upgrade Roundcube…this will normally output an error giving you insight on what the problem is, or even sometimes fix it :)

To force a Roundcube upgrade on a cPanel server run this command via SSH:

/usr/local/cpanel/bin/update-roundcube –force

While attempting to upgrade the script output something that pointed right to the problem:

Archiving current Roundcube data to /var/cpanel/roundcube/roundcube.backup.sql mysqldump: Got error: 144: Table ‘./roundcube/contacts’ is marked as crashed and last (automatic?) repair failed when using LOCK TABLES Failed to backup existing Roundcube DB. DB likely did not exist.Cleaning old Roundcube data archives

Roundcube Logs

To check if this was the only error we might as well check the logs as well.  Roundcube stores error logs (really just logs in general) in a specific location on cPanel servers, you can find them at:


You can monitor the output of the error log by using this command via SSH:

tail -f /var/cpanel/roundcube/log/errors

You can then repeat the the process and see what error is output.  You can also just omit the  -f from above to output the last few lines in the error log.
In my case I found this error multiple times:

DB Error: Table ‘./roundcube/contacts’ is marked as crashed and last (automatic?) repair failed (SQL Query: SELECT *
Repair Database

The output from the error log and the installer point right to what is causing the problems with adding a contact to the address book.  After reading around on a few sites I found that a handful of people have had similar issues when upgrading roundcube, so my only assumption is this may have caused it when cPanel upgraded last.  Either way, the fix is easy and all we need to do is repair the database.

To run a repair on the Contacts table in the Roundcube Database, run this command via SSH:

cd /var/lib

sudo -u mysql myisamchk -r -v -f mysql/roundcube/contacts

Force Install/Upgrade of Roundcube

Now that we’ve repaired the database, lets try to force the upgrade again and hopefully not find any other errors:

/usr/local/cpanel/bin/update-roundcube –force

How to Prevent unauthorized WordPress wp-admin and wp-login.php attempts

How to lock down and password protect your WordPress website from invalid login attempts. We’ll do this by limiting access to the /wp-admin directory and the wp-login.php script.

Password protect WordPress logins

Using the steps below to create password protection for your /wp-admin directory. We’ll also copy those rules over to protect your wp-login.php script.

Please note that users have reported to us in certain cases following these steps will result in a re-direct loop. If you’re having that issue, please ensure you have the following two entries at the top of both .htaccess files:

ErrorDocument 401 “Denied”
ErrorDocument 403 “Denied”

You may get password prompts even when you aren’t trying to login to WordPress. Usually this is because of plugins. Please make sure to allow /wp-admin/admin-ajax.php requests without password protection.

Reseller Hosting Offer: Get additional 12 months including Free WHMCS | ENOM Reseller |SSL/IP’s

Reseller Hosting Offer: Get additional 12 months including Free WHMCS | ENOM Reseller |SSL/IP’s

1. Login to your cPanel.

2. Under the Security section, click on Password Protect Directories.

3. select document root click go Select the Document Root for your domain, then click Go.

4. click on wp adminClick on your wp-admin directory

5. Check Password protect this directory, give it a name, then click Save.

6. Now click on Go Back.

7.  Click on Password Generator.
Click on Generate Password a few times, and copy your password.
Check I have copied this password in a safe place.
Then click Use Password.

8. Now type in a Username, then click on Add/modify authorized user.

9. Try to access your /wp-admin directory.
Your browser will prompt you for the username/password you just created.
Type them in, and click Log In

10. Your normal WordPress admin login page should now display.

You might encounter a re-direct loop at this point. If so, please ensure you’ve created the error documents mentioned earlier in this article.

11.  Now go back to cPanel.
Under the Files section, click on File Manager.
Select the Document Root for your domain.
Check Show Hidden Files (dotfiles), then click Go.

12. From the left-hand directory listing, expand public_html.
Click on wp-admin, then right-click on your .htaccess file.
Then click on Edit
For the encoding pop-up, click on Edit again to bypass that.
13. Copy all the code in the .htaccess file.

While you still have the /wp-admin/.htaccess file open, also go ahead and add the code in colour:

ErrorDocument 401 “Denied”
ErrorDocument 403 “Denied”

# Allow plugin access to admin-ajax.php around password protection
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any

AuthType Basic
AuthName “Secure Area”
AuthUserFile “/home/example/.htpasswds/public_html/wp-admin/passwd”
require valid-user

14. From the left-hand directory listing, click on public_html.
Right-click on your .htaccess file, then click on Edit.

15. Now paste the .htaccess code you copied, in-between some <FilesMatch> tags, so that it ends up looking like this:

ErrorDocument 401 “Denied”
ErrorDocument 403 “Denied”

<FilesMatch “wp-login.php”>
AuthType Basic
AuthName “Secure Area”
AuthUserFile “/home/example/.htpasswds/public_html/wp-admin/passwd”
require valid-user

Then click on Save Changes up at the top-right.

16. Now if someone tries to directly login via wp-login.php they will be prompted for a valid user as well.

17. When a user enters invalid credentials are, they will get an Authorization Required error. They will then not be able to attempt to login to your WordPress admin directly.

How to Install MOD_FASTCGI on cPanel server

Installation requirements for compilation

# yum install httpd-devel apr apr-devel libtool

Download latest mod_fastcgi source code

# cd /opt
# wget

Untar the package.

# tar -xvzf mod_fastcgi-current.tar.gz

Install the module. You can find the installation guide on the INSTALL.AP2 file. We have to specify top_dir in the make and make install commands because we install apache2/httpd using yum

# cd mod_fastcgi-2.4.6
# cp Makefile.AP2 Makefile
# make top_dir=/usr/lib/httpd
# make install top_dir=/usr/lib/httpd

(IF there is error you can use the command
apxs -n mod_fastcgi -i -a -c mod_fastcgi.c fcgi_buf.c fcgi_config.c fcgi_pm.c fcgi_protocol.c fcgi_util.c)

Add “LoadModule fastcgi_module modules/” to /etc/httpd/conf/httpd.conf to tell apache to load the new module

Restart apache

# /etc/init.d/httpd restart

How to fix “ undefined symbol: zend_atol” error

If you are getting error as

“/usr/bin/php: symbol lookup error: /usr/local/lib/php/extensions/no-debug-non-zts-20060613/ undefined symbol: zend_atol”

then disable the suhosin by commenting

extension=”” to ;extension=””

and add line suhosin.simulation On in the php.ini file.

If you don’t have the access to php.ini file you can FTP / login to cPanel >> File Manager >> create a custom php.ini  file under the public_html folder and add the above lines (;extension=””  &  suhosin.simulation On)

Increase size for /tmp partition (Linux Server)

In order to increase the size of /tmp partition. Go through the following steps :

1. First stop MySQL, Apache, and cPanel to prevent writing to the /tmp partition :

root@dodg [~] #  /etc/init.d/mysql stop
root@dodg [~] #  /etc/init.d/httpd stop
root@dodg [~] #  /etc/init.d/cpanel stop

2. Take a backup of the current /tmp folder.

root@dodg [~] #  tar -czfv tmp.tar.gz tmp

3. Umount /tmp partition. If you’re unable to, you can do an lsof to see what processes are still writing to it, and kill them off.

root@dodg [~] #  umount tmp

4. Delete /usr/tmpDSK

root@dodg [~] #  rm -rf /usr/tmpDSK

5. Now edit the file /scripts/securetmp. Search for “tmpdsksize” and set the size you want in MB.

root@dodg [~] #  vi /scripts/securetmp

$tmpdsksize = 512000 (change the “512000? value to your desired size in MB)

Save and quit the file.

This will recreate your /tmp (tmpDSK) partition using the size you specified. While the securetmp script may be overwritten in a cPanel update, the size of /tmp will not be affected one you alter its size.

6. Now you can untar the /tmp backup

root@dodg [~] #  tar -xzvf tmp.tar.gz

7. Start all the services.

root@dodg [~] #  /etc/init.d/mysql start
root@dodg [~] #  /etc/init.d/httpd startssl
root@dodg [~] #  /etc/init.d/cpanel start

Installation Mono Framework on Linux Server (CentOS)

When you compile Mono from the source, you can install newer versions than are offered by Novell.

Mono versions are available at:

Let’s Install all the Dependencies
Run the below as root

# yum install bison gettext glib2 freetype fontconfig libpng libpng-devel libX11 libX11-devel glib2-devel libgdi* libexif glibc-devel urw-fonts java unzip gcc gcc-c++ automake autoconf libtool make bzip2 wget

Time to Download and Compile
Run the below as root

# cd /usr/local/src

# wget

# tar zxvf mono-2.10.8.tar.gz

# cd mono-2.10.8

# ./configure –prefix=/usr/local

# make && make install

If you do receive “Out of Memory” errors, run the below:

# ulimit -v unlimited

WHMCS Security Release 4.5.6 and 5.2.6 Update

whmcs logoWHMCS has released new patches for the 4.5, 5.0, 5.1, and 5.2 minor releases. These updates provide targeted changes to address security concerns with the WHMCS product. You are highly encouraged to update immediately.

WHMCS has rated these updates as including critical or important security impacts.

The following full-release versions of WHMCS have been published and address all known vulnerabilities:

The latest public releases of WHMCS are available inside members area at WHMCS.

WHMCS has been updated to 5.2.6 in Softaculous as well. If you have Softaculous installed on your server you can upgrade to the latest version of WHMCS via Softaculous.

PLEASE NOTE: The 4.5 series reached End Of Life as of June 30th 2013. WHMCS is aware that some customers have not moved to an LTS version due to the newness of the LTS policy. The related 4.5 patch release published along with this Security Advisory is provided as a courtesy to those customers. From this point forward, there will be no more patches provided for 4.5 or any other release that has reached EOL.

There is no reason to believe that these vulnerabilities are known to the public. As such, WHMCS will only release limited information regarding the vulnerabilities at this time.

Once sufficient time has passed to allow WHMCS customers to update their installed software, WHMCS will release additional information regarding the nature of the security issue.

These Targeted Security Releases and Patches address 9 vulnerabilities in WHMCS versions 4.5, 5.0, .5.1, and 5.2.

Source :

Entire Server Migration

To take backup for entire server:
To take username alone
# cat /etc/trueuserdomains | awk ‘{print$2}’ >> /home/test  —-to take username
# for i in `cat 1.txt`;do /scripts/pkgacct $i; mv /home/cpmove-$i.tar.gz /home/Migration/;done    (first create a folder as migration first, then run the cmd)
here 1.txt is a file name…you can replace it by file.txt bt the line should be cat file.txt
# scp -rp * destination location (it will migrate whole account in this server)
then restore using the below script
for x in $(cat 1.txt); do /scripts/restorepkg /home/cpmove-$x.tar.gz; done;  (if it is tar.gz format)
for x in $(cat 1.txt); do /scripts/restorepkg /home/$x.tar; done; (if it is tar format)
cat1.txt should contain all the accounts username which you want to restore (just the name of the user)
 To delete the acct
  for i in `cat delete`; do yes |/scripts/killacct $i;sleep 1; done;
for i in `cat 1.txt`;do /scripts/pkgacct $i; mv /home/cpmove-$i.tar.gz /home/Migration/;done
for i in `cat znteccn.txt`;do /scripts/pkgacct $i; mv /home/cpmove-$i.tar.gz /home/Migration/;done
for x in $(cat 1.txt); do /scripts/restorepkg /home/cpmove-$x.tar.gz; done;
for i in `cat /etc/trueuserdomains | awk ‘{print $2}’`; do /scripts/pkgacct $i; done
for i in `cat text`;do /scripts/pkgacct $i;done

How to monitor and Deal with Spamming ?

It is difficult to track nobody spammers from exim_mainlog file. You can’t get exactly that who is using your server to send spams. If you check php.ini file you will see that the mail service is set to /usr/sbin/sendmail and almost all mail scripts are in use the built in mail(); function for PHP.It means that everything is going through /usr/sbin/sendmail.

We will try to get these users in your Linux Servers.

1. Login to server as root.

2. For safe side turn off exim.

[root@server~]#/etc/init.d/exim stop

3. Backup /usr/sbin/sendmail file. [Your server is using Exim as MTA (Mail Transfer Agent), Exim will use sendfile for just a pointer actually].

[root@server~]#mv /usr/sbin/sendmail /usr/sbin/sendmail.hidden

4. Now we will create a spam monitoring script for the new sendmail programme.

[root@server~]#pico /usr/sbin/sendmail

Paste in the following:

# use strict;
use Env;
my $date = `date`;
chomp $date;
open (INFO, “>>/var/log/spam_log”) || die “Failed to open file ::$!”;
my $uid = $>;
my @info = getpwuid($uid);
print INFO “$date – $REMOTE_ADDR ran $SCRIPT_NAME at $SERVER_NAME n”;
else {
print INFO “$date – $PWD – @infon”;
my $mailprog = ‘/usr/sbin/sendmail.hidden’;
foreach (@ARGV) {
$arg=”$arg” . ” $_”;
open (MAIL,”|$mailprog $arg”) || die “cannot open $mailprog: $!n”;
while (<STDIN> ) {
print MAIL;
close (INFO);
close (MAIL);

5. Change the permissions new sendmail.

[root@server~]#chmod +x /usr/sbin/sendmail

6. New log file to save history which using web mail scripts.

[root@server~]#touch /var/log/spam_log

[root@server~]#chmod 0777 /var/log/spam_log

7. Start Exim.

[root@server~]#/etc/init.d/exim start

8. Now try any formmail script or any mail script which uses mail function and monitor new log file (spam_log)

[root@server~]#tail – f /var/log/spam_log

It should give us output like this:

Mon Nov 15 11:00:00 EST 2008 – /home/username/public_html/directory/subdirectory/subsubdirectory – nobody x 99 99 Nobody / /sbin/nologin

9. Log Rotation: This file is not set to be rotated file so there is a possibility that the file comes very large soon in size. So do this,

[root@server~]#pico /etc/logrotate.conf

Find >>

# no packages own wtmp — we’ll rotate them here

/var/log/wtmp {
create 0664 root utmp
rotate 1

Add >>

# SPAM LOG rotation

/var/log/spam_log {
create 0777 root root
rotate 1

10. We will set attributes for new sendmail programme file so it will not get overwritten.

[root@server~]#chattr + i /usr/sbin/sendmail

Now we can get nobody spam users, Goodluck.

How to disable Root Login in cpanel server?

As you dig deeper into server administration, you’ll eventually need to log into your server via SSH as root. Logging into your server as root allows you to easily accomplish many tasks, but it demands a certain level of security precaution.

SSH root logins offer a huge potential security vulnerability. The root user is the administrative user of a server and has full access to the server. If compromised, the root account provides the malicious user with complete control. Anyone logged into a server with root access can write, erase, edit, upload or download any file. It is an all-access pass to your server, and simply guarding your root password isn’t enough to protect yourself.

Disabling SSH root logins

Because of the security risks inherent in direct SSH root access, nearly all VPS packages, including ServInt VPS and Flex dedicated accounts, will be delivered with direct root access disabled by default. If, for some reason, this is not done by your host, you will need to do disable it from the command line in /etc/ssh/sshd_config. Ask your host for more details before editing this file.

Configuring SSH root escalation for cPanel users

Configuring SSH root escalation for a user in cPanel can be accomplished for any server with SSH access by simply adding that cPanel account to the Wheel Group. To do so:

Log into WHM
Navigate to Security Center » Manage Wheel Group Users
Choose the cPanel user and then click Add to Group.
Once done, you will need to restart the SSH from WHM via Restart Services » SSH Server (OpenSSH).

Configuring SSH root escalation for non-cPanel users

To configure SSH root escalation for a non cPanel user, you will need to add that user to the wheel group in WHM (above) and then complete one other step: editing the password file of your server.

Log into the server with root access
Open the password file (located in /etc/passwd)

Note: if you do not know how to open and edit a file directly on the command line, you can learn how to use an editor such as nano.

Each line of the file is for one user. Locate the user you are granting access to and edit the text of that line changing /bin/false to /bin/bash.
Restart the SSH service, either through WHM as outlined previously or using the command “sshd restart”.

Escalating to root as a superuser

With these steps complete, the user can now escalate to root when logged into the server via SSH with their standard credentials. Once logged into the server via SSH, the user simply types the command “su” (superuser) and hits Return. The user will be prompted for the root password and when entered correctly will become the root user.