Disable SSLv2 on cPanel and Apache Ports

On this post we are going to show how to quickly patch a common PCI Vulnerability Alert that says something like this:
“The remote service appears to encrypt traffic using SSL protocol version 2?.

In Apache common ports 80 and 443, you need to modify the SSLCipherSuite directive in the httpd.conf or ssl.conf file.
An example would be editing the following lines to something like:

SSLProtocol -ALL +SSLv3 +TLSv1

After you have done this, if you see you are still getting PCI Compliance vulnerability emails regarding to this issue its probably that cPanel is still allowing SSLv2 on their ports.

To quickly disable SSL version 2 on cPanel ports: 2082, 2083, 2086, 2087, 2095, 2096. You will need to do the following:

edit /var/cpanel/cpanel.config and change nativessl=1 to nativessl=0

This will make cPanel to use sTunnel.

edit /usr/local/cpanel/etc/stunnel/default/stunnel.conf

and add:

options = NO_SSLv2

just below the “Authentication stuff” tab.

After you have done all this you will need to restart cPanel:

/etc/init.d/cpanel restart


How to quickly check this?

SSH to your server and type the following commands

root@cPanel [~]# openssl s_client -ssl2 -connect localhost:2096
root@cPanel [~]# openssl s_client -ssl2 -connect localhost:2083
root@cPanel [~]# openssl s_client -ssl2 -connect localhost:2087
root@cPanel [~]# openssl s_client -ssl2 -connect localhost:2086

If everything is fine you should receive something like this,

root@cPanel [~]# openssl s_client -ssl2 -connect localhost:2096

Upgrade Openssl to 0.9.8k

On some old systems like centos 4.5, 4.7 openssl will need to be upgraded to newest version
Here are the steps to upgrade :

cd /usr/src
wget http://www.openssl.org/source/openssl-0.9.8k.tar.gz
tar -xvzf openssl-0.9.8k.tar.gz
cd openssl-0.9.8k
./config –prefix=/opt/openssl shared
make;make test;make install
/scripts/upcp –force

Running upcp after building fixes the openssl-devel files.
However, even though “openssl version” returns 0.9.8.k, apache still uses 0.9.7.a. I realize this has redhat security backports.

How to Add Services to Chkservd

From http://www.v-nessa.net/

(Sexy g33k chicks rock…)

Chkservd is the service in cPanel that checks to make sure that services are running, then restarts them if necessary. It’s also responsible for the ‘Service Manager’ section in cPanel, which is an interface where added services can be easily checked on and off.
To add a new service, create a line in /etc/chkserv.d/chkservd.conf in the same format as the others:


1 means the service should be enabled, 0 means it’s off.
In /etc/chkserv.d each service has its own file. Create a file called as the name of the service you are monitoring. The contents of the file are in the format of:


There are two ways that cPanel checks services with chkservd:

* Connection-based monitoring – By default, cPanel will try to connect to the service’s specified port, issue a command, and if a response is received within 10 seconds it will consider the service to be online. For instance, FTP:


* Process-based monitoring – cPanel will check for a specific process to determine whether it is online. For instance, named:


If you have more than one restart command, you can separate them with semicolons in order of preference that they should be run. Output of these commands will be logged to the chkservd.log
After you’ve created the service’s configuration file, restart chkservd:

/etc/init.d/chkservd restart

You should then see the service listed in WebHost Manager in the ’service manager section’
Chkservd logs are in /var/log/chkservd.log. Checks are done every 8 minutes, and everyone online service gets a +, offline services get a -. If the service is determined to be offline, the restart command(s) specified in that service’s chkservd configuration file is issued and the output is logged.

If you don’t even have chkservd installed, it’s probably missing and you need to install it.

Setting up cPanel Proxies

From http://www.v-nessa.net/

(Sexy g33k chicks rock…)

It’s been about a while since cPanel 11.1 came out and the proxy script from cpanelproxy.net that we all know and love stopped working. Well, the cPanel devs came through for us again and incorporated an Apache-based proxy feature to natively allow users behind firewalls to connect to cPanel over port 80, similar to the way the previous php-based cpanel proxy worked. This was a peace of cake on new server setups, where all you had to do was check on the proxy options in WHM “Tweak Settings” and include mod_proxy in your Apache build. However, I had a very difficult time getting this to work on previous servers that did not already have those features. After bringing this up to Mr. Ken from cPanel (who, by the way, is the most awesomest person in the cpanel bunch), I was finally able to come up with a procedure for getting this to work without having to completely recompile Apache which is a no-no on more mature production servers.

First, if you haven’t already, run a cpanel update to the latest version which at the time of my writing is 11.23. Once the update is complete, log into WHM > Tweak Settings and check off these options (only the first is required):

Add proxy VirtualHost to httpd.conf to automatically redirect unconfigured cpanel, webmail, webdisk and whm subdomains to the correct port

Automatically create cpanel, webmail, webdisk and whm proxy subdomain DNS entries for new accounts.

Allow users to create cpanel, webmail, webdisk and whm subdomains that override automatically generated proxy subdomains

Now, to install mod_proxy (for Apache 1.3 and 2.x)

Download the source for your Apache version. If you’re not sure what that is, you can find out from your phpinfo file or in some cases by typing ‘httpd -v’ from command line.

wget http://apache.mirrors.tds.net/httpd/apache_1.3.41.tar.gz
tar -xvzf apache_1.3.41.tar.gz
cd apache_1.3.41/src/modules/proxy (will just be /modules/proxy for Apache 2 sources)

You need to compile the mod_proxy module with apxs to add it to httpd.conf. For Apache 1.3.x:

/usr/local/apache/bin/apxs -i -a -c mod_proxy.c

For Apache 2.2 (not sure about 2.0 since we don’t run that version on any of our systems) I found that you have to compile mod_proxy with two of its submodules in order for the proxy feature in cpanel to work:

/usr/local/apache/bin/apxs -i -a -c mod_proxy.c proxy_util.c
/usr/local/apache/bin/apxs -i -a -c mod_proxy_http.c

The restart Apache and verify that it is able to start. In my case, when I just compiled the mod_proxy module I got some error about ap_proxy_lb_workers, but when I added proxy_util that fixed the problem. Then I wasn’t able to get the cpanel proxy feature to work without mod_proxy_http. There is one last step with Apache, where you need to add the proxy virtualhost entries in. cPanel has this set up as one virtualhost entry for all the subdomains as well as https, which didn’t quite work in my case because we have shared SSL certificates on the main IP. So I added the following lines between the tags for the main hostname and shared ssl hostname:

ServerAlias cpanel.* webmail.*
RewriteEngine On
RewriteCond %{HTTP_HOST} ^cpanel\.
RewriteRule ^/(.*)$1 [P] RewriteCond %{HTTP_HOST} ^webmail\.
RewriteRule ^/(.*)$1 [P] UseCanonicalName Off

These are just the ones for webmail and cpanel, but webdisk and whm ones can be added as well.

All you need to do now is setup the subdomains so that customers can access them. The best way to do this is to specify the username:

/scripts/proxydomains –user=username add

To do all accounts on the server (which can take a while):

/scripts/proxydomains add

To list all the options for this script simply type /scripts/proxydomains .

Where Does cPanel Put Things?

From http://www.v-nessa.net/

(Sexy g33k chicks rock…)

I can think of a few things that are wrong with that title but in all seriousness…don’t you ever wonder where cPanel stores the config changes that you make in WHM? Automation is the key nowadays, and lately that’s required me to get a little down and dirty with cPanel to find its deepest secrets. *This information is not official documentation, nor is it backed up by cPanel or set in stone. In other words, don’t blame me if you mess up your server.

These are files that store the information read and used by WHM (as of 11.23.6)

* IP addresses: /etc/ips
* Reserved IPs: /etc/reservedips
* Reserved IP reasons: /etc/reservedipreasons
* IP address pool: /etc/ipaddrpool
* Access hash (WHM remote access key): /home/user/.accesshash or /root/.accesshash
* cPanel update preferences: /etc/cpupdate.conf
* Basic cPanel/WHM setup: /etc/wwwacct.conf
* System mail preferences: /etc/localaliases
* Exim open relay list: /etc/alwaysrelay
* Server-wide max emails per hour: /var/cpanel/maxemailsperhour
* Tweak settings: /var/cpanel/cpanel.config
* Packages: /var/cpanel/packages/
* Features: /var/cpanel/features/
* User data: /var/cpanel/users/ and /var/cpanel/userdata
* Apache templates: /var/cpanel/templates/apache(1,2)
* Exim config template: /etc/exim.conf.localopts
* Exim mail IPs: /etc/mailips
* rDNS for mail ips: /etc/mail_reverse_dns
* Clustering: /var/cpanel/cluster/root/config
* Service manager: /etc/chkserv.d
* Users and their domains: /etc/userdomains
* Users and their main domains: /etc/trueuserdomains
* Users and their owners: /etc/trueuserowners
* Main cPanel IP: /var/cpanel/mainip
* cPanel version: /usr/local/cpanel/version
* Resellers: /var/cpanel/resellers
* Reseller nameservers: /var/cpanel/resellers-nameservers

These are a few scripst that you can use to achieve the same results of their WHM equivalents:

* Initialize quotes: /scripts/initquotas
* Compile Apache: /scripts/easyapache (you can pass additional options – see EasyApache 2 docs)
* Update cPanel: /scripts/upcp
* Enable/disable tweak settings: /scripts/smtpmailgidonly on|off
* Change PHP API and suExec settings: /usr/local/cpanel/bin/rebuild_phpconf
* Suspend an account: /scripts/suspendacct
* Terminate an account: /scripts/killacct

Obviously there are a ton more, and just about anything done in WHM can be done directly on the server. The main things to remember:

Scripts are mainly stored in /scripts and /usr/local/cpanel/bin

Data files are in /var/cpanel

Config files are in /etc/ and /usr/local/cpanel

Compiz Check

From forlong’s Blog

Compiz-Check is a script to test if Compiz is able to run on your system/setup and if not, it will tell you the reason why.

Additionally you can use the output of the script to look for support in the official Compiz Fusion forums or the mailing list / forum of your distribution, which will make it much easier to locate your problem.

The script is suitable for GNOME, KDE and Xfce users and is not limited to a specific Linux distribution – in fact, the script lists those infos for you.

The test consists mainly of three parts:

1. List relevant system information
2. Run several Compiz related checks
3. Check for problematic hardware and problems with the setup in use.

So the output will eventually look like this:

Gathering information about your system…

Distribution: Ubuntu 8.04
Desktop environment: GNOME
Graphics chip: ATI Technologies Inc RV350 AR [Radeon 9600] Driver in use: radeon
Rendering method: AIGLX

Checking if it’s possible to run Compiz on your system…

Checking for texture_from_pixmap… [ OK ] Checking for non power of two support… [ OK ] Checking for composite extension… [ OK ] Checking for FBConfig… [ OK ] Checking for hardware/setup problems… [ OK ]

If anything is OK like in this example, your system is most probably able to run Compiz.
In case anything fails, you will be prompted a reason and ideally a hint how to solve the problem.

Compiz-Check will not run Compiz for you, nor will it do any changes to your system (unless you specifically say so).

Download & Usage
Do not just copy & paste the following to your blog/forum – find out why

The script is available here.
You can use this command to download it to your home directory:

wget http://blogage.de/files/9124/download -O compiz-check

Afterwards, you have to make it executable:

chmod +x compiz-check

And finally run it like this:


How to Install Software from a Tarball in Linux

Posted June 25th, 2009 by Joshua Price in Linux

Most of the time, installing software in Linux is a breeze. Package management utilities like Apt, Portage, and Yum have made software installation in Linux even easier than it is in Windows (in my opinion at least). If you know what you want, you simply tell your package manager that you want it, and it’ll find, download, install, and configure your new package for you.

Sometimes, however, the package doesn’t exist in your distribution’s repositories. Often, in cases like that, your only option is to download a tarball (usually .tar.gz, .tar.bz, or .tgz) which contains the source code for the program that you have to compile yourself. While it may be a little intimidating at first, compiling from source is normally a quick and easy process. Today, we’ll learn how.

First off, I should note that not all tarballs are the same. This guide will be assuming that the program you’re trying to install is a normal GNU-style source code collection. Most require all the steps noted below, but many skip one step or another. For the purposes of the tutorial I’ll be compiling the source code package of Python 3.0.1 from the Python homepage.
Step 1: Extract the tarball

For those new to Linux, tarball is a term commonly used to refer to a file which contains other files. It’s a lot like a ZIP or RAR file in Windows, except that the tar program, on its own, does not compress the files. Tar works with a compression program like gzip to actually compress the files, which is why you commonly see two extensions (.tar and .gz). This is sometimes abbreviated to just .tgz.

Fortunately, we don’t need to run two separate programs to extract the files, we just tell tar to run the files through gzip to decompress. You can use a graphical utility to extract those files by simply double clicking the tarball from your file manager, or you can do it from the command line with:

tar -zxvf mytarball.tar.gz

The options we gave tar are as follows:

* -z to tell tar to run this file through gzip to decompress (use -j for bzip files)
* -x to extract the files
* -v for “verbose”, so we can see a list of the files it’s extracting
* -f to tell tar that we’re working with a file

For easier unzipping, see the Tips section at the bottom of this page

Once the files are extracted, open a command terminal and go to the directory where the files have been unzipped. Before we can compile, we need to run the configure script. The job of the configure script is to check your system for all the software necessary to compile the program from source code into a usable binary program. It looks for things like gcc version and other tools needed to build the software. So once you’re in the directory with all the files that were unpacked from the tarball, type in


If all goes well it’ll go through a check of various parts of your system, then drop you back to the command line like below:

Running the configure script

The most common cause of errors in this step is a missing dependency. Look closely at any errors you may get to determine what package is missing.

This is the real meat of the process – where we compile the source code into a runnable program. This is normally the easiest step, only requiring a single command. If the configure step completed without errors, simply type in


On a large program, this step might take a few minutes. Once done, you’ll be dropped back to the shell prompt as shown here.

Compilation stage

Technically, your program is now ready to use. Under most circumstances, however, you’ll want to run one more step so that she program can be fully installed into the correct locations for it to be run from anywhere.
Make install

All this really does is copy the now-compiled program into the system directories like /usr/bin so that it can be run from any directory without having to specify a path to the files. Since it’s copying to a directory outside your home, you’ll probably need root privileges. If the make step completed without errors, simply run

sudo make install

to copy the files. At this point, you’re all done! Your new program can be used like any other.

Chances are, you’ll be compiling from source more than once in your life. In fact, for those who like to use the latest and greatest software, this can be very common. To make it a little easier, open your .bashrc file from your home directory, and add the following aliases to the end:

alias ungz=”tar -zxvf”
alias unbz=”tar -jxvf”
alias cmi=”./configure && make && sudo make install”

Install Smarty

This is a simple guide to get Smarty setup and running quickly. The online
documentation includes a very thorough explanation of a Smarty installation.
This guide is meant to be a quick and painless way of getting Smarty working,
and nothing more. The guide assumes you are familiar with the UNIX system
environment. Windows users will need to make adjustments where necessary.


Copy the Smarty library files to your system. In our example, we place them in

wget http://www.smarty.net/do_download.php?download_file=Smarty-2.6.26.tar.gz
gtar -zxvf Smarty-2.6.26.tar.gz
cd Smarty-2.6.26
mkdir /usr/local/lib/php/Smarty
cp -r libs/* /usr/local/lib/php/Smarty

You should now have the following file structure:



You will need four directories setup for Smarty to work. These files are for
templates, compiled templates, cached templates and config files. You may or
may not use caching or config files, but it is a good idea to set them up
anyways. It is also recommended to place them outside of the web server
document root. The web server PHP user will need write access to the cache and
compile directories as well.

In our example, the document root is /web/www.domain.com/docs and the
web server username is “nobody”. We will keep our Smarty files under

$> cd /web/www.domain.com
$> mkdir smarty
$> mkdir smarty/templates
$> mkdir smarty/templates_c
$> mkdir smarty/cache
$> mkdir smarty/configs
$> chown nobody:nobody smarty/templates_c
$> chown nobody:nobody smarty/cache
$> chmod 775 smarty/templates_c
$> chmod 775 smarty/cache


Now we setup our application in the document root:

$> cd /web/www.domain.com/docs
$> mkdir myapp
$> cd myapp
$> vi index.php

Edit the index.php file to look like the following:

< ?php // put full path to Smarty.class.php require('/usr/local/lib/php/Smarty/Smarty.class.php'); $smarty = new Smarty(); $smarty->template_dir = ‘/web/www.domain.com/smarty/templates’;
$smarty->compile_dir = ‘/web/www.domain.com/smarty/templates_c’;
$smarty->cache_dir = ‘/web/www.domain.com/smarty/cache’;
$smarty->config_dir = ‘/web/www.domain.com/smarty/configs’;

$smarty->assign(‘name’, ‘Ned’);



$> vi /web/www.domain.com/smarty/templates/index.tpl

Edit the index.tpl file with the following:


Hello, {$name}!

Now go to your new application through the web browser,
http://www.domain.com/myapp/index.php in our example. You should see the text
“Hello Ned!” in your browser.

How To Reset Linux Firewall Automatically While Testing Configuration With Remote Server Over SSH Session

Q. I’d like to tell my Linux iptables firewall to flush out the current configuration every 5 minutes. This will help when I’m testing a new rules and configuration options. Some time I find myself locked out of my own remote server. How do I reset Linux firewall automatically without issuing hard reboot?

A. You can easily flush out current configuration using iptables command and shell script combo. There is no built in option for this kind of settings. So you need to write a small shell script and call it from crontab file.
Create a firewall reset shell script

Create a /root/reset.fw script:

# reset.fw – Reset firewall
# set x to 0 – No reset
# set x to 1 – Reset firewall
# —————————————————————————————————————
# Added support for IPV6 Firewall
# —————————————————————————————————————
# Written by Vivek Gite
# —————————————————————————————————————
# You can copy / paste / redistribute this script under GPL version 2.0 or above
# =============================================================

# set to true if it is CentOS / RHEL / Fedora box

### no need to edit below ###

if [ “$x” == “1” ];
if [ “$RHEL” == “true” ];
# reset firewall using redhat script
/etc/init.d/iptables stop
/etc/init.d/ip6tables stop
# for all other Linux distro use following rules to reset firewall
### reset ipv4 iptales ###
for table in $(

Enable register_globals for a single domain

How to enable register_globals for a single website without putting the entire server security at risk?
* In your file manager, enter the public_html folder.
* In the public_html folder you will see a file called .htaccess.
* Select the .htaccess file and click on edit in the upper right hand corner.
* Copy and paste the text line shown below at the bottom of .htaccess file and then save it:

php_value register_globals 1

This will turn your register_globals on and your script will work properly. Why is register_globals disabled in the first place? Leaving register_globals turned on poses a security risk for an entire web server. It should therefore only be enable on a case by case situation and only per website. Web Developers should no longer develop scripts that require register_globals to be turned on. Unfortunately this is very difficult to enforce.

If yours is off and you want to enable it use:
php_value register_globals 0
You may also want to create your own php.ini and add it to the cgi_bin. You can write a single file with the name php.ini in the root directory of your hosting account. In that file write this:
register_globals = Off
memory_limit = 120M
This also addresses the memory limit error which may hamper some installs.