I don’t know about you other cPanel system admins out there, but I find WHM to be very useful for the more advanced and time-consuming tasks, such as installing SSL certificates. However, the easy stuff like changing an account’s package and resetting passwords is a royal pain in the ass as far as convenience is concerned when you have to log into WHM, list accounts, and make whatever change.

I recently became favorable towards the WHM XML API functionality which will let me do a majority of the everyday account-related tasks from command line without ever opening my browser, which is a lot easier when managing thousands of users across multiple servers. Below are a couple scripts I’ve put together using the XML API from a base script in the cPanel forums:

Change account password

Change account package

Both are run via command line, and the arguments passed to the PHP script as variables. For example, to change an account’s password:

./chacctpass myuser mypass1234

Customizing these scripts to perform different functions is easy via the following steps:

- change if ($argc != 3) to the number of command line arguments you wish to pass to the script plus one. In the above example there are two arguments and since the script name counts, add one and that makes 3.

- in the section where the arguments are assigned to variables (like $cpuser, etc), name your variables. The first one should have an array value of 0, then 1, 2, etc.

- edit the usage example, which will come up if the required number of arguments is not provided…you can add any text you like

- if you’re using a hash (which is more secure than user/pass authentication), go fetch your remote access key from WHM and put it in the $hash value within quotes, format intact. Otherwise, put in your WHM user’s username and password

- change the $server variable to your server’s hostname

- change $apipath to the WHM path for the function you are using. You can find a whole list of them here, and most will give you the path to use in the examples sections. In the API path, insert your variable names where the values are suppose to be. For instance:

$apiPath = “/xml-api/passwd?user=myuser&pass=mypass1234″;

Would be:

$apiPath = “/xml-api/passwd?user=$cpuser&pass=$newpass”;

In the header section, uncomment whichever $header .= “Authorization: line that matches your authentication method (user/pass or hash)

Once you’ve configured your API script, chmod to 700 and run from the command line as show in my example. It’s better to lock down the script by changing its ownership only to the user that will be using it, and not giving read, write, or execute permissions to anyone else.

Note: for these scripts to work you have to have PHP compiled with OpenSSL support, otherwise change the socket variables to http over port 2086.

See also: http://www.thecpaneladmin.com/pci-compliance-package-cpanel-servers/

Those of you who are server admins or use certain merchant services know what I’m taking about — it’s that dreaded security scan that picks apart your server to tell you everything that it thinks is wrong, assuming you have the knowledge or access to fix it: yes, the PCI scan. PCI compliancy is a somewhat new procedure used by security companies and financial institutions to measure the security of a webserver that collects and stores sensitive information. The reasons for getting a scan vary, but are most commonly for legal reasons or just the assurance that your server is subject to certain vulnerabilities.

After dealing with 2-3 PCI scans a week for the last year, I’ve put together a common procedure for how to make your server compliant to current PCI standards. Note that each scan company is different and may report other issues, and if you’re using ControlScan then, well, I feel sorry for you. I’m also assuming that you are on a Linux server running cPanel and LAMP.

Step 1: Make sure you have a firewall

PCI scans are nazis about unjustified open ports, so only open the ones that you need in order for services to run effectively. Manually configuring iptables is a pain in the ass, so I recommend using APF or CSF (if you have cPanel) and then configuring the allow rules to only allow ports for active services.

Note that both indicate the opening of cPanel ports 2082, 2095, and 2086, but some scans will complain about these being nonsecure. If that is the case you can configure within WHM to only use the secure ports, then remove the nonsecure ones from the firewall so they can’t be accessed. You should also close MySQL port 3306 for external hosts and allow them on a per-IP basis to anyone other than localhost has to be allowed.

Step 2: Update your system

This is an obvious one, but you’d be surprised how many people still have old packages installed on the server. With cPanel, running /scripts/upcp will usually update the vital system software as long as you have your update configuration in WHM set to allow it, but otherwise I would recommend doing a yum update, up2date, or whatever else you use to manage packages to make sure everything is up to date.

Nowadays old versions of MySQL, PHP, and Apache are no longer squeezing through either, so you need to upgrade to at least MySQL 4.1.22, PHP 5.2.5, and Apache 1.3.39 (some scans will want Apache 2.0.x).

Step 3: FIx OpenSSL

If you did a package update this was probably already taken care of, but if you installed via source you need to make sure you’re using at least 0.9.7j, which is the oldest version that most PCI scans allow. You can get your sources from here, and it may require a recompile of Apache and other services that use it. To check your OpenSSL version, type ‘openssl‘ from your SSH prompt and then type ‘version‘.

Note to Redhat/Fedora/CentOS users: If you’re running a somewhat recent version of your OS your openSSL version probably is something like 0.9.7a, but due to Redhat backporting this may be a false-positive. If you’re on any Redhat-based distribution, just tell your scan company and they’ll bypass OpenSSL checks.

Step 4: Check your SSL certificates

In order to pass a PCI scan your server must have at least one SSL certificate signed by a recognized certificate authority, and any services using SSL need to be using a certificate as well. Go cough up $30-$100 and buy a decent 264-bit SSL certificate and install it not just for Apache, but also for all of your active services. WebHost Manager has a section for installing service SSL certificates to make this process easier.

Step 5: Disable SSLv2 and other weak encryption methods

This one always gets me, because there is no way to disable SSLv2 for everything at once, at least not one that I know of. What makes this part the worse is that not all services support the choosing of SSL protocols and ciphers, but luckily unless you are using ControlScan the ones that don’t are probably not going to show up. Here’s how you do it for common services that are reported:

Apache:

Add these lines to your httpd.conf (you may to add them to each secure vhost as well):

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

POP3 and IMAP:

Edit the following files:

/usr/lib/courier-imap/etc/pop3d-ssl
/usr/lib/courier-imap/etc/imapd-ssl

Comment out the existing TLS_CIPHER_LIST line and replace it with the following and restart courier-imap:

TLS_CIPHER_LIST="ALL:!SSLv2:!ADH:!NULL:!EXPORT:!DES:!LOW:@STRENGTH"

Exim:

Add the following to exim.conf:

tls_require_ciphers = ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:!SSLv2

For other services that might be on your system, take a look at this guide.

Step 6: Disable mod_userdir (or whatever cPanel is calling it nowadays)

If you are able to go to http://yourserverip/~yourusername, then you have mod_userdir enabled and the scan will probably complain. You can disable this in WHM under Security Center > Apache mod_userdir Tweak, or in httpd.conf add “userdir disabled user1 user2 user3 …etc”

Step 7: Put Apache in incognito mode and disable the bad stuff

If you try to get an Apache error (like a 404 error), the footer of that page probably contains more information that you may want to share about your Apache setup. You can disable this in your httpd.conf by adding these lines:

ServerSignature Off
ServerTokens Prod
FileETag None

You can read more about these here.

Another thing that some scans report is the use of 413 errors. You should add this line to httpd.conf as a workaround:

ErrorDocument 413 /index.php (or any other file)

Just about all scans will complain if the ‘trace’ and ‘track’ apache methods are enabled on your server. You can fix this by adding these lines to your Virtualhost entries or .htaccess files:

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)$ [NC]
RewriteRule ^.*$ - [F]

You should also disable directory indexes, which can be done most easily in your cPanel’s index manager. Directory indexes allow the listing of files inside folders that do not have an index page. You can also disable these in your .htaccess files:

Options All -Indexes

Ending notes

Really, it doesn’t matter how secure your server is if your web application scan is poorly programmed, so your server should not be the ending point in security. Some PCI scan companies are able to detect common vulnerabilities in web applications, but you should take the extra steps to stay ahead of the game and update your site software on a regular basis.

I know you’ve provably seen a lot of guides on how to install ffMPEG, but I’ve noticed that most of them are incomplete and don’t cover the possible issues that can arise during installation. I’ve installed ffMPEG on dozens of servers and have devised a standardized procedure on what I feel is the best way to perform this installation.

This walkthrough has been tested on systems running Redhat 9, RHEL 4, and CentOS 4.5 and it may also work on other distributions and versions. Our servers also run cPanel 11, but this is in no way required in order to install ffMPEG. I assume at this point that you have root access and that yum (or another similar package manager) is installed.

ffMPEG commonly consists of and includes the following software:

- Essential / MPlayer
- FLVtool2 (Requires a Ruby Core)
- LAME MP3 Encoder
- php-ffMPEG
- ffMPEG
- libOgg
- libvorbis

To start out, enter into a temporary source directory and download all the binaries:

cd /usr/src
wget http://www3.mplayerhq.hu/MPlayer/releases/codecs/essential-20061022.tar.bz2
wget http://www4.mplayerhq.hu/MPlayer/releases/MPlayer-1.0rc2.tar.bz2
wget http://rubyforge.org/frs/download.php/17497/flvtool2-1.0.6.tgz
wget http://easynews.dl.sourceforge.net/sourceforge/lame/lame-3.97.tar.gz
wget http://superb-west.dl.sourceforge.net/sourceforge/ffmpeg-php/ffmpeg-php-0.5.0.tbz2

*These are the latest stable versions at the time this article was written. If you are unable to download any of the above, you’ll need to visit the distributor’s site and download the latest stable version available.

Now extract everything:

bunzip2 essential-20061022.tar.bz2; tar xvf essential-20061022.tar
tar zxvf flvtool2-1.0.6.tgz
tar zxvf lame-3.97.tar.gz
bunzip2 ffmpeg-php-0.5.0.tbz2; tar xvf ffmpeg-php-0.5.0.tar
bunzip2 MPlayer-1.0rc2.tar.bz2 ; tar -xvf MPlayer-1.0rc2.tar

Create and import the Codecs directory:

mkdir /usr/local/lib/codecs/
mv essential-20061022/* /usr/local/lib/codecs/
chmod -Rf 755 /usr/local/lib/codecs/

Install Subversion and Ruby

yum install subversion
yum install ruby  (If you're on cPanel you can alternatively use /scripts/installruby)
yum install ncurses-devel

Get ffMPEG and MPlayer from SVN:

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg
svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer

Install LAME:

cd /usr/src/lame-3.97
./configure && make && make install

Install libOgg and libVorbis:

yum install libogg.i386
yum install libvorbis.i386
yum install libvorbis-devel.i386

Install flvtool2

cd /usr/src/flvtool2-1.0.6/
ruby setup.rb config
ruby setup.rb setup
ruby setup.rb install

Install MPlayer:

cd /usr/src/MPlayer-1.0rc2
./configure && make && make install

Install ffMPEG:

cd /usr/src/ffmpeg/
./configure --enable-libmp3lame --enable-libvorbis --disable-mmx --enable-shared
make && make install

This is the typical configure line that I use, but you can customize this to what you need. For available configure options, type ./configure –help. Your custom configuration may require the installation of additional software on the server.

ln -s /usr/local/lib/libavformat.so.50 /usr/lib/libavformat.so.50
ln -s /usr/local/lib/libavcodec.so.51 /usr/lib/libavcodec.so.51
ln -s /usr/local/lib/libavutil.so.49 /usr/lib/libavutil.so.49
ln -s /usr/local/lib/libmp3lame.so.0 /usr/lib/libmp3lame.so.0
ln -s /usr/local/lib/libavformat.so.51 /usr/lib/libavformat.so.51

You may get an error about a library path not being found, if so, run

export LD_LIBRARY_PATH=/usr/local/lib

If this is being installed on a dedicated server, you might also get an error about the /tmp directory not be executable, which is common when installing on a dedicated server with a separate /tmp partition mounted noexec. In this case, you will need to create a tmp dir in the ffmpeg folder and use that as the tmp disk for now:

mkdir tmp
chmod 777 tmp
export TMPDIR=./tmp

Then run the configure command and set the TMPDIR variable back.

export TMPDIR=/tmp

Install ffMPEG-php

cd /usr/src/ffmpeg-php-0.5.0/
phpize
./configure && make && make install

ln -s /usr/local/bin/ffmpeg /usr/bin/ffmpeg
ln -s /usr/local/bin/mplayer /usr/bin/mplayer

When the installation is complete, it will give you a long path to the shared libraries. This needs to be copied to the php.ini as so:

[ffmpeg]
extension=/usr/local/lib/php/extensions/no-debug-non-zts-20020429/ffmpeg.so

or in most cases where the extension_dir variable is set, just do:

extension="/ffmpeg.so"

The ‘no-debug-non-zts-xxxxxxxx’ directory will be the one provided during installation. When this is done, restart Apache and check that the module is loaded in PHP:

/etc/init.d/httpd restart
php -r 'phpinfo();' | grep ffmpeg

Look for this:

ffmpeg
fmpeg support (ffmpeg-php) => enabled
ffmpeg-php version => 0.5.0
ffmpeg.allow_persistent => 0 => 0

If you only get output for the ‘PWD’ variables, make sure that the extension_dir path is correct in the phpinfo file. Sometimes there are two specified, and if that is the case then the incorrect one should be commented out.

Test out ffmpeg for errors just by typing ffmpeg at the command line. The most common error is:

ffmpeg: error while loading shared libraries: libavformat.so.51: cannot open...

To correct this, edit /etc/ld.so.conf and add the line

/usr/local/lib

then save and exit.

Now run this command to reload the library cache:

ldconfig -v

You’re all done…enjoy!

We recently started installing suPHP on a few of our servers, which is an implementation of phpsuexec, only a ton faster and with less overhead. Yesterday I posted a tutorial on how to install suPHP on a PHP5/Apache server outside of EasyApache, but today I shall go over how to enable PHP directives in your .htaccess instead of using the php.ini.

First of all, if you’d rather use the .htaccess than the php.ini capabilities of a phpsuexec environment, then shame on you. But, we have some customers who are terrified of php.ini and would rather use the .htaccess. So what? Ok, well there is a workaround. Mr. Joye released a newer version of htscanner that now works with suPHP, and allows you to use php directives in your .htaccess just like you did when PHP was installed as and Apache module. All you have to do is download the tarball and install like any other PHP module:

wget http://pecl.php.net/get/htscanner-0.8.1.tgz

tar -xvzf htscanner-0.8.1.tgz

cd .htscanner-0.8.1

./configure && make && make install

Then add a loader for the resulting binary to your php.ini:

extension=”/htscanner.so”

From here, you can add your php_value and php_flag statements to your .htaccess as usual within <ifmodule> tags. I should note that the reason why you normally would not be able to overwrite php.ini values in your .htaccess is because .htaccess is an Apache file. Under phpsuexec/suPHP, PHP runs as a CGI module so Apache does not understand what those mean, so it will either ignore them all together or return a nasty 500 error.

So it’s official, I’ve started my Ruby programming classes in school and I’ll finally be able to see what it can do.  We started offering Ruby on some of our servers here and we’re all learning a little bit about it before we start offering it on our mainstream hosting…because you have to have at least one person who knows the feature well enough to help other people.  From what I’ve played with so far it seems to be the same logic as PHP and perl, so let’s just see how it goes.  For those of you wanting to try out some Ruby, there’s a nifty little Ruby emulator and mini-tutorial at http://tryruby.hobix.com/

It surprises me how often people get nervous over installing things just because it’s new to them. The other day I had a guy harass our technical support for 20 minutes on the phone because he was wanted to install SHOUTcast. Honestly, before then I had never installed SC simply because I don’t use it, but all he had to do was RTFM (which is what I did)…but we all know that customers don’t like to read documentation and would rather you do everything for them.  Don’t get me wrong, I mean, part of my job is consulting with people on things like this and I enjoy doing it, but there’s a line to draw when the answer is right in front of you and you just don’t want to look.

So, here it is…a dumbed down and simplified tutorial for SHOUTcast. Yes, you can do this without the help of your hosting company, only you might need to the open your SC port in the firewall (don’t expect them to do this if you’re on a shared server)

Create a folder in the outside public_html, like sc or shoutcast, then download the Shoutcast server files from http://www.shoutcast.com/download/files.phtml:

mkdir sc
cd sc
wget http://www.shoutcast.com/downloads/sc1-9-8/sc_serv_1.9.8_Linux.tar.gz
tar -xvzf sc_serv_1.9.8_Linux.tar.gz
chmod 755 sc_serv
cd ..
chown -R user:user sc

This will put three files on the server:

README.TXT
sc_serv
sc_serv.con

From here, the configure the Shoutcast server and setup via the sc_serv.conf. However, take note of what port that Shoutcast server will be running on so it can be enabled in the server firewall. This is set in the sc_serv.conf file as well:

PortBase=8000

Once the configuration is complete the SC server needs to be started. As long as you have SSH access you can start it yourself. To start the server, type:

./sc_serv &

To stop the server, just do a killall -9 sc_serv. Note the ‘&’ after the command, which is one of the few techniques used to keep a process running even after your SSH session closes.

I don’t know if it’s just me, but it seems that CentOS is kinda slow with their software updates. It’s not too big of a deal since CentOS is based off of RHEL so you can usually use RHEL 4-5 RPM’s, but those usually bombard me with failed dependencies. I find that the generic x86 RPMs do the trick, so for any of you trying to update your Subversion installations to a more recent version, here’s what you have to do on CentOS:

Optionally remove the old version by running yum remove subversion (assuming you installed with Yum)

wget http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/rhel-4/i386/subversion-1.4.5-1.i386.rpm
wget http://www.eu.apache.org/dist/apr/binaries/rpm/i386/apr-1.2.8-1.i386.rpm
wget http://www.eu.apache.org/dist/apr/binaries/rpm/i386/apr-util-1.2.8-1.i386.rpm

rpm -i apr-util-1.2.8-1.i386.rpm
rpm -i apr-1.2.8-1.i386.rpm
rpm -i subversion-1.4.5-1.i386.rpm

Some people may have to do a ‘yum install postgresql-libs’ as for some reason APR wants that stuff.

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.

Hosting companies have all kinds of tactics to keep spam away from their customers, but one very common complaint I get is the amount of spam coming in through contact forms. Even though we don’t allow ‘nobody’ mail through the php mail() function and we provide the best server-side spam filters available, local mail cannot be filtered or limited. In other words, no spam filter in the world is going to save you from your shitty contact form.

I started recommending to our customers to implement MX checks in their forms as spam bots nowadays can easily get past things like captcha and textual confirmations. Spammers rarely send email from valid mail hosts so it’s very easy to filter these out with just a few lines of code:

<?php
list($user, $domain) = split(“@”, $email);
if (checkdnsrr($domain, “MX”)) {
} else {
}

?>

To explain the code a little bit, you’re basically taking your stored email address variable ($email) and using the split() function to single out the domain name into one variable, $domain. When you pass the domain through the checkdnsrr() function, PHP will return either a ’1′ or ’0′ result, which is interpreted as either true or false. The above is just the basic code, but you can have it spit out errors as well:

if (checkdnsrr($domain, “MX”)) {
} else {

echo "Invalid email";
}

The checkdnsrr() function can also be used to check for other records as well, like A, CNAME, NS, etc.

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.