How to install/upgrade roundcube in a cPanel/Linux server

Before installing roundcube on a cPanel server you should know your mysql root password. Replace DATABASEPASSWORD with your mysql root password.

If Roundcube is already installed, you need to uninstall it.

Uninstall/remove exiting RoundCube

# cd /usr/local/cpanel/base

# rm -rf roundcube*

On mysql prompt

mysql -e ‘drop database roundcube’;

# /scripts/upcp

Now follow the  steps to update/install latest roundcube. You will have to specify your root password when prompted.

# cd /usr/local/cpanel/base

# wget -O roundcube.tar.gz

# roundcubemail/roundcubemail-0.2.1.tar.gz

# rm -rf roundcube.tar.gz

# mv -f roundcubemail-0.2.1/ roundcube

# cd roundcube

# chmod -R 777 temp

# chmod -R 777 logs

Database Configuration

Create the database, database user and install the intial sql file. The following commands will do this for you.

mysql -e “CREATE DATABASE roundcube;”

mysql -e “GRANT ALL PRIVILEGES ON roundcube.* TO [email protected] IDENTIFIED BY



mysql -e “use roundcube; source SQL/mysql.initial.sql;”

You will have to replace the roundcube password with ‘DATABASEPASSWORD’ field.

Roundcube Configuration

# cd config

# mv

# mv

then open database configruation file in your favroite editor.

# vi

Find following line

$rcmail_config[‘db_dsnw’] = ‘mysql://roundcube:[email protected]/roundcubemail’;

Replace it with

$rcmail_config[‘db_dsnw’] = ‘mysql://roundcube:DATABA[email protected]/roundcube’;

Now Open

# vi


$rcmail_config[‘default_host’] = ”;

Replace with

$rcmail_config[‘default_host’] = ‘localhost’;

Configure cPanel to show roundcube in the theme. Please note this is for the X theme(default) only!! If you use another theme please skip the next part and see below.

# cd /usr/local/cpanel/base/roundcube/skins/default/images/

# cp –reply=yes roundcube_logo.png /usr/local/cpanel/base/frontend/x/images/roundcube_logo.png

# cp –reply=yes roundcube_logo.png /usr/local/cpanel/base/webmail/x/images/roundcube_logo.png

# cd /usr/local/cpanel/base

# wget

# patch -p0 < HGpatch-roundcube-1.0BETA2

# chattr +i /usr/local/cpanel/base/frontend/x3/webmaillogin.html

# chattr +i /usr/local/cpanel/base/webmaillogin.cgi

Restart the mysql, cpanel services on your server. You are done!, have fun with your new Roundcube installation!!

You can access roundcube by

no mysql database size shown in cpanel

You may see the mysql database size is zero in cPanel >> Mysql Databases, though the databases contains tables and data. In order to include the size of the databases while displaying disk usage in cPanel/WHM, use either of the following steps:

1) SSH to your server as root and edit the cpanel.config file

# vi /var/cpanel/cpanel.config

Search for


and change to


If the parameter is not present, add it. Save the file and execute the following command:

# /scripts/update_db_cache

OR You may use follwing option in WHM

2) Login to the WHM, goto Tweak Settings >> ‘SQL’ section and enable the following option:

When displaying disk usage in cpanel/WHM include Postgresql and MySQL.

You are done.

Cpanel error Fantastico is not installed at the default location

While accessing the Fantastico in cpanel, you may encounter following error,

Fantastico is not installed at the default location /usr/local/cpanel/3rdparty/fantastico. Either move the Fantastico directory from it’s current location to /usr/local/cpanel/3rdparty/fantastico OR enable ioncube loaders in WHM -> Tweak settings.

To resolve the issue

Make sure ioncube loader is installed and enabled on server. You can check it in WHM >> Tweal Settings

If its not working,

You need to compile cpanel PHP (not server PHP) by

# /scripts/makecpphp

This updates/compiles the version of PHP that cPanel uses internally. Not the same as the PHP account users use to execute scripts. The internal PHP binary is used for the cPanel installed version of PHPMyAdmin, Horde, Squirrelmail and any other PHP Webapp that is internal to cPanel/WHM.

After cpphp, if its still showing the same error,

Try to update the cpanel installation by,

# /scripts/upcp –force

This should resolve the issue.

phpMyadmin error in a cPanel server

Sometimes you may face following error in phpmyadmin

Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly.

First thing you’ll neet to do is to check the error logs.(Generally its here /usr/local/apache/logs/error_log). You will probably see errors referencing permission errors writing to your session directory.

Just  change the permission of the session directory (chmod 777) you should be good to go.

If no success….

Login in to the Shell with the root user and then open the file using your favorite editor.

# vi /usr/local/cpanel/3rdparty/etc/phpmyadmin/php.ini

Search for session.save_path and change the following
session.save_handler = sqlite
session.save_path = /var/cpanel/userhomes/cpanelphpmyadmin/sessions/
session.save_handler = files
session.save_path = /tmp
Save & Exit
Restart apache

If after upgrade its reverting back, or you don’t want to change the session.save_path in php.ini for phpmyadmin

# mkdir -p /var/cpanel/userhomes/cpanelphpmyadmin/sessions
# chmod 1777 /var/cpanel/userhomes/cpanelphpmyadmin/sessions

and restart the apache service.

You are done !

Rkhunter installation and cron Job Setup

Rkhunter is RootKit Hunter. It is a scanning tool which will scan for rootkits, backdoors, and local exploits. RKHunter will ensure you about 99.9% that your dedicated web server is secure.

# cd /usr/local/src/

# wget

# tar -xzvf rkhunter-*.tar.gz

# cd rkhunter*

# ./ –install

You can test the installation by typing following command.
Note: If successful, this scan will take about 2/3 minutes to complete.

# /usr/local/bin/rkhunter –c

Update rkhunter by

# rkhunter –update

Setup RKHunter to e-mail you you daily scan reports.

# vi /etc/cron.daily/

Add The Following:


(/usr/local/bin/rkhunter -c –cronjob 2>&1 | mail -s “Daily RKHunter Scan Report” [email protected])

# chmod +x /etc/cron.daily/

You can set up the cron as below as well.


( /usr/local/bin/rkhunter –versioncheck

/usr/local/bin/rkhunter –update

/usr/local/bin/rkhunter –cronjob –report-warnings-only

) | /bin/mail -s ” rkhunter output” [email protected]

You have now setup a daily cron, that will email you the results of your RKHunter scan.


rkhunter <parameters>

–checkall (or -c)Check the system, performs all tests.
–createlogfile*Create a logfile (default /var/log/rkhunter.log)
–cronjobRun as cronjob (removes colored layout)
–help (or -h)Show help about usage
–nocolors*Don’t use colors for output (some terminals don’t like colors or extended layout characters)
–report-mode*Don’t show uninteresting information for reports, like header/footer. Interesting when scanning from crontab or with usage of other applications.
–skip-keypress*Don’t wait after every test (makes it non-interactive)
–quick*Perform quick scan (instead of full scan). Skips some tests and performs some enhanced tests (less suitable for normal scans).
–versionShow version and quit
–versioncheckCheck for latest version

DDOS attack prevention by using mod_evasive

What is Mod_evasive?

One way to stop one of the more basic attacks on a server is mod_evasive. This article will assist you the process of installing and configuring mod_evasive. This apache module will help you to protect the server against people sending too many requests to the webserver in an attempt to flood it. If it detects too many connections from a specific IP, that  IP  will be blocked on the server. This is especially useful when the server is continuously attacked. With the default configuration it will block the offending IP for 10 minutes. If it continues to try and flood mod_evasive will automatically add more time to this.


Follow these commands for Apache 1.3.x.
# cd /usr/local/src
# wget
# tar -zxf mod_evasive_1.10.1.tar.gz
# cd mod_evasive
# /usr/local/apache/bin/apxs -cia mod_evasive.c
Follow this commands for Apache 2.0.x.
# cd /usr/local/src
# wget
# tar -zxf mod_evasive_1.10.1.tar.gz
# cd mod_evasive
# /usr/sbin/apxs -cia mod_evasive20.c


If you are adding this module to apache 1.3.x, the following lines need to be added to the httpd.conf  below the AddModule section.

<IfModule mod_evasive.c>
DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 100
DOSPageInterval 2
DOSSiteInterval 2
DOSBlockingPeriod 600

If you are using apache 2.0.x, you need to scroll down to the LoadModule section in the httpd.conf and add the following:

<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 100
DOSPageInterval 2
DOSSiteInterval 2
DOSBlockingPeriod 10
DOSBlockingPeriod 600

Exit and save the httpd.conf

Now you need to restart the apache service..

# service httpd restart

It should be working for you.


The hash table size defines the number of top-level nodes for each child’s hash table. Increasing this number will provide faster performance by decreasing the number of iterations required to get to the record, but consumes more memory for table space. You should increase this if you have a busy web server. The value you specify will automatically be tiered up to the next prime number in the primes list (see mod_evasive.c for a list of primes used).


This is the threshold for the number of requests for the same page (or URI) per page interval. Once the threshold for that interval has been exceeded, the IP address of the client will be added to the blocking list.


This is the threshold for the total number of requests for any object by the same client on the same listener per site interval. Once the threshold for that interval has been exceeded, the IP address of the client will be added to the blocking list.


The interval for the page count threshold; defaults to 1 second intervals.


The interval for the site count threshold; defaults to 1 second intervals.


The blocking period is the amount of time (in seconds) that a client will be blocked for if they are added to the blocking list. During this time, all subsequent requests from the client will result in a 403 (Forbidden) and the timer being reset (e.g. another 10 seconds). Since the timer is reset for every subsequent request, it is not necessary to have a long blocking period; in the event of a Ddos attack, this timer will keep getting reset.

How to enable allow_url_fopen for a single domain in a cPanel server

The way to enable allow_url_fopen on a phpsuexec and a non-phpsuexec server is different. For security reasons the option is mostly disabled server wide, however, you can turn it ON for a single domain/account if it is required.

Its pretty simple to enable it.

On a non phpsuexec server:

# cd /usr/local/apache/conf/
see if you have a “userdata” directory there? If not, create the “userdata/” directory and then the file allowurl.conf inside it. So the complete path should look like:

# vi /usr/local/apache/conf/userdata//allowurl.conf
and add the following to the file
php_admin_value allow_url_fopen On
php_admin_value allow_url_include On

Now, edit the Apache configuration file and scroll down to the VirtualHost entry of the domain. Include the path of the above created file in it, as shown below:

Include “/usr/local/apache/conf/userdata//allowurl.conf”
Save the file and rebuild the apache configuration by

# /usr/local/cpanel/bin/apache_conf_distiller –update
# /usr/local/cpanel/bin/build_apache_conf
# /scripts/restartsrv httpd
This will enable allow_url_fopen for that domain.

On a PHPSuExec Or SuPHP server:
On a SuPHP enabled server, turning ON allow_url_fopen in the VirtualHost entry won’t work since PHP is not working as a Apache Handler anymore.

In such a case, copy the global php.ini of the server under directory of the domain, say public_html (you need to copy php.ini to the directory, where your script with allow_url_fopen resides)

# cp /usr/local/lib/php.ini /home//public_html/
Edit the new php.ini file and enable allow_url_fopen in it

allow_url_fopen = On
Save the file. That’s it.

please replace “” with the actual username of the domain wherever stated above.

PHP memory limit errors in wordpress

In wordpress, you may face PHP memory limit error and encounter following error,

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2348617 bytes) in /home4/xxxxxx/public_html/wp-includes/plugin.php on line xxx

Such error is due to PHP Memory Limit set by the host, this value is set in server’s php.ini file . You  can overcome this issue by,

  • Increasing the limit via php.ini file

You can directly increase the PHP Memory Limit if you’ve access to the php.ini file. With some hosts, you may not have access to php.ini , in that case ask your host to copy php.ini file to your public_html folder or respective folder where wordpress is installed or you can create a file called php.ini. It can be set by editing value as

memory_limit = 64M

You can change the value as per your requirement.

  • Changing PHP memory limit in wp-config.php

If you don’t have access to php.ini file, alternative value can be set in wp-config.php. You need to edit wp-config.php and add following line after the <?php tag

define(‘WP_MEMORY_LIMIT’, ’64M’);

save the file and check.

  • Modification of the .htaccess file

This is alternative way, a very simple one.  You need to set proper value by editing .htaccess file as below.

php_value memory_limit 64M

  • Setting php memory value in install.php

This is yet another way to increase the PHP Memory Limit of your WordPress. There is an install.php file in the wp-admin folder of the WordPress installation.

All you should do is just add the command ini_set(‘memory_limit’,’64M’)in the install.php file. You will see the PHP Memory Limit increased.

  • Installing a wordpress plugin

If all above steps are not working, you can try installing proper wordpress plugin which monitors the memory usage or adds proper value in wp-config.php file (with 256MB limit) automatically and no need to edit the php file or set memory limit any where. Just install and activate it.

You can check the plugin here.

Exim error after migrating to new server

Some times following errors may be seen after migrating to new server.

failed to expand condition “${if exists {$home/etc/$domain/quota}{${if > {${lookup{$local_part}lsearch{$home/etc/$domain/quota}{$value}{0}}}{0}{${if eq {${if exists {$home/mail/$domain/$local_part/maildirsize}{1}{0}}}{0}{${if > {${run {/usr/local/cpanel/bin/eximwrap GETDISKUSED $local_part $domain}}}{${lookup{$local_part}lsearch{$home/etc/$domain/quota}{$value}{0}}}{true}{false}}}{${perl{checkuserquota}{$domain}{$local_part}{$message_size}{${lookup{$local_part}lsearch{$home/etc/$domain/quota}{$value}}}{$home/mail/$domain/$local_part/maildirsize}}}}}{false}}}{false}}” for virtual_user_maildir_overquota router:

You may face such issue due to array or one (or more) of the accounts had a quota usage that exceeded Exim’s hard coded limit,which can be resolved by executing

# /scripts/reset_mail_quotas_to_sane_values

on your server.