The [pretty much] Complete Guide to Installing ffMPEG and Audio Binaries

Posted by Nessa | Posted in uncategorized | Posted on 07-01-2008


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

*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:// ffmpeg
svn checkout svn:// 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

HTML Email Template Pack - PC Version

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/ /usr/lib/
ln -s /usr/local/lib/ /usr/lib/
ln -s /usr/local/lib/ /usr/lib/
ln -s /usr/local/lib/ /usr/lib/
ln -s /usr/local/lib/ /usr/lib/

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/
./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:


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


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:

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: cannot open...

To correct this, edit /etc/ and add the line


then save and exit.

Now run this command to reload the library cache:

ldconfig -v

You’re all done…enjoy!

How to Rearrange Your Package

Posted by Nessa | Posted in uncategorized | Posted on 20-12-2007


For some odd reason, Ubuntu and other Debian-based distros don’t like the standard x86 RPMs that most vendors package their software in. If you want to install a third-party RPM, you have to use alien to repackage the RPM into a .deb file before you can install it:

sudo apt-get install alien
alien -k your-rpm-file.rpm

This will convert the RPM to a .deb file. From here you can use dpkg to install it:

sudo dpkg -i your-rpm-file.deb

Upgrade to Subversion 1.4.x on CentOS

Posted by Nessa | Posted in uncategorized | Posted on 04-12-2007


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)



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.

How to Upgrade PHP

Posted by Nessa | Posted in uncategorized | Posted on 04-12-2007


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


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‘.


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:


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/

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.

GRUB Errors on Windows Dual Boot

Posted by Nessa | Posted in Uncategorized | Posted on 30-11-2007


I don’t want to admit that I still have PC’s that dual boot Windows XP and Vista, but given the occasional problems I have after Ubuntu and Fedora updates I’m not ready to give them up yet. Some time in the middle of the night last night my laptop, which used to dual boot Ubuntu and Vista (before I deleted the Ubuntu partition), rebooted and left me with a ginormous GRUB loader error:

GRUB Loading stage 1.5

GRUB loading, please wait...
Error 15

The issue is that the boot loader probably went apeshit and doesn’t know what to do.  Since Windows is the MBR nazi, it’s best to use Windows to fix it.

Luckily with all the luck I’ve had with Vista I still had the install CD and was able to recover quickly. For those of you at home, if you don’t have the original install CD you need to create a boot disk and slide it in <insert giggle here>. From the CD, when the menu comes up hit ‘R’ for recovery console which will bring you into the Windows command line. If you’re using the boot disk, you should already be there.

From the command line type ‘fixmbr‘ (or fdisk /mbr for versions < XP) and then you should be able to successfully boot into Windows XP (or Linux).

If you’re still running Linux on dual boot, another option is to run the recovery from the Ubuntu CD.  However, this can take a lot of time and if you don’t know what you’re doing you may end up deleting your OS.

How to Commit Genocide on Annoying Processes

Posted by Nessa | Posted in Uncategorized | Posted on 21-11-2007


A few days ago I came across some processes on one of our servers that just wouldn’t die. Even after doing a kill -9 and all that good stuff, more would just keep spawing until there were dozens running on the machine. A head system admin of ours gave me this command, which will mass-kill all alike processes so they don’t have a chance to re-spawn each other.

The processes running were all some form of “init_”, like init_1, init_13, etc. To kill these:

ps aux |grep init_ |awk ‘{print $2}’ |awk ‘{print “kill -9 ” $1}’ | sh -v

The ‘grep init_’ should reflect the common name of all the processes.

Installing IonCube loader with Zend Optimizer

Posted by Nessa | Posted in Uncategorized | Posted on 18-11-2007


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 and pick your download. This example assumes that you are using php 5.2.

cd /usr/src
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>/

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):


Above this section, add this line:


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.

Switching from Windows to Ubuntu

Posted by Nessa | Posted in Uncategorized | Posted on 18-11-2007


I was doing some checking and I found a few websites that have really good tutorials on how to switch from Windows to Ubuntu:

One thing I should mention from personal experience is that the Migration Assistance really sucks sometimes. When I first installed Ubuntu it was quick and painless, but upon a re-install on a dual boot machine the installer would infinitely stick on the account migration. If this happens to you, you’ll need to reboot from the CD, log into the terminal, then run the installer without the Migration Assistant:

user@localhost:~$ ubiquity –migration-assistant

Yum GCC Errors

Posted by Nessa | Posted in Uncategorized | Posted on 17-11-2007


This is coming from Shelby as a fix for the CentOS gcc compiler error that occurs when you try run a Yum update on some systems:

--> Processing Dependency: glibc-common = 2.3.4-2.25 for package: glibc-dummy-centos-4
--> Finished Dependency Resolution
Error: Missing Dependency: glibc-common = 2.3.4-2.25 is needed by package glibc-dummy-centos-4

First you have to remove the existing package:

yum remove glibc-dummy-centos-4

Then you have to reinstall gcc:

yum install gcc & yum install gcc*

Then you should be able to proceed running the yum update command.

Securing the TMP Partition and Tracking Hacks

Posted by Nessa | Posted in Uncategorized | Posted on 16-11-2007


Are your temp partitions putting out behind your back? Anyone who’s ever administered a Linux server would know the risk of leaving the /tmp directory unsecured, moreso on a webserver that is shared among multiple websites.

The tmp directory is world-writeable and used by a majority of services on a machine — including the storage of PHP and MySQL session files. One issue that I’ve seen on older servers is that one customer’s poorly-coded website would get exploited and end up downloading a file into the /tmp directory, then have that hack file executed on the server as a nobody-owned process. Hack processes are the easiest to find, as they always have a little something extra.

This should go without saying, but hack processes can run from almost anywhere, not just /tmp. I’m mainly bringing up the tmp directory because it’s the most targeted location for hack files if it isn’t secured properly.

Identifying Hack Processes

To start out, log into your server as root as issue the following command to see all the nobody-owned processes running on the machine. This is assuming that Apache on your webserver runs as ‘nobody':

root@localhost[~] ps -efw |grep nobody |more

A majority of the output will reflect legitimate Apache processes:

nobody 8748 25841 0 21:35 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 8785 25841 0 21:35 ? 00:00:01 /usr/local/apache/bin/httpd -DSSL
nobody 8988 25841 0 21:36 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL

You’ll see that they all have the same parent process ID of ‘25841’ and all of the commands look about the same. However, you may see something that looks like this:

nobody 15707 26407 0 11:18 ? 00:00:00 [sh <defunct>]
nobody 15717 1 0 11:18 ? 00:00:04 /usr/bin/perl
nobody 13016 1 0 14:14 ? 00:00:00 /usr/bin/perl

nobody 8988 1 0 21:36 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL -d3

All of these are hack processes. A few things to look for:

– Perl and shell (sh) processes on most systems run as the user that is executing them, not ‘nobody’. If this is true on your system, a nobody-owned perl process is probably a hack

– The parent ID of the process is different than all the others of the same service — these can be easily faked

– For Apache, an extra little switch on the end of the command (../httpd -DSSL -d3) – ‘d3′ is usually the name of the hack file that is being executed through Apache (not always).

Now I know you probably have the urge to kill -9 it, but don’t. Killing a hack process before determining what it is or where it came from is only going to let it happen again.

Tracking the process:

Once you know which processes should not be running, you need to know where they came from. The *easiest* way to track a process is through the lsof command. If you take the process ID (not the parent) and run an lsof it will tell you everything you want to know:

lsof -p 8748

From here I can see that this process is running from a folder in a user’s account. All I need to do now is kill it off, then remove the hack files from that user’s directory and let them know to update their shit.

TMP Directory Hacks

I’ve seen my fair share, but many hack processes will be spawned from the temp partitions of the server (like /tmp, /tmpDIR, /dev/shm), as these are usually set to 777 to allow programs to store their temporary files. When you first look in your TMP directory you’re going to see a lot of stuff — this is normal, but you’ll want to look for nobody-owned files that stand out. Just a hint, some hacks will try to trick you with their names. I have seen many that are named “…” or “httpd” to make them look legitimate, but I know that httpd (the service that runs Apache) should not be in the tmp directory…and that’s what makes it stand out.

Securing the tmp Partition

I’m not going to go too far into this here, because there’s already a very sexy website with this information available.

If you are on a cPanel server, you should run /scripts/securetmp in addition to following the instructions above.