Tag Archives: directadmin

FreeBSD 7.2 amd64, VMWare ESXI 4.0 and DirectAdmin

I recently acquired a new Dell R610 server for my web hosting clients. Here’s how I set it up under ESXI 4.0 and configured it for the best performance.

Specifications of the Dell R610

  • 2x Intel Xeon E5530 Quad Core 2.4 GHZ
  • DDR3 24 GB at 1 GHZ
  • 6x 146GB SAS 10K RPM in RAID 6. I chose redundancy over performance (RAID 10). With the PERC 6i controller, there is very little penalty in performance when it comes to RAID 6.
  • Redundant power supplies; hot swappable drives

Initial Setup and Configuration of the Server

  1. Enable Virtualization support in the R610 BIOS. By default, it is disabled, and must be enabled for ESXI 4.0 to function properly.
  2. Install VMWare ESXI 4.0 onto the SD card. The SD card is quite reliable and is only needed to boot the ESXI kernel into memory.
  3. Once installation is complete, go ahead and create your FreeBSD 7.2 virtual machine. I gave my server 16 GB of RAM, 4 cores and about 450 GB of hard drive space.

FreeBSD Installation

Installing FreeBSD 7.2 amd64 is easy. Here is what my mounts look like:

  • / – 1024 MB
  • SWAP – 4096 MB
  • /var – 10 GB
  • /tmp – 2GB
  • /usr – the remainder, 432 GB here

FreeBSD Updating

Before we move on to installing open-vm-tools and DirectAdmin, I want to do some basic updates to the core system. I won’t be installing any of the web services (Exim, Apache, MySQL, etc.) because DirectAdmin takes care of all that for me.

  • Update ports via CVSup. This will take a bit of time the first time you run it.
  • freebsd-update fetch / install. This installs the latest security patches and keeps your FreeBSD installation up to date.
  • Install wget: make install clean -C /usr/ports/ftp/wget/. I am installing this now because I don’t want DirectAdmin to install its own version.
  • Add WITHOUT_X11=yes in /etc/rc.conf to prevent X11 stuff from installing. This is a server, not a desktop!

FreeBSD Configuration for VMWare ESXI 4.0

Install Open VM Tools:

# make install clean -C /usr/ports/emulators/open-vm-tools-nox11

An error message will appear when trying to install fusefs-kmod:

===> fusefs-kmod-0.3.9.p1.20080208_05 requires the userland sources to be installed. Set SRC_BASE if it is not in /usr/src. *** Error Code 1

The quick fix for this is as follows (source):

csup -g -L2 -h cvsup.freebsd.org /usr/share/examples/cvsup/stable-supfile

This will pull down all the userland sources and allow fusefs-kmod to compile correctly. Once the synchronization has been finished, you can go ahead and resume the installation of Open VM Tools (just type “make install clean” again).

Modify rc.conf so it loads the Open-VM-Tools:


Install DirectAdmin

Installing DirectAdmin is easy, just follow their instructions. You’re done.

How to get Clip-Share 4.0.9 Working on FreeBSD 6.3

REVISED: Mencoder 1.0rc2 has too many problems with WMV files. Modified the guide to work with Mencoder 1.0rc1 instead. Also, added the necessary steps to install GCC 4.2 to compile FFMPEG correctly.


For the past week, I have been trying to figure out how to get Clip-Share 4.0.9 working on a FreeBSD system. Uploading script files are easy, but when it comes to compiling and installing binaries, everything can go wrong and then some. I wanted to install everything from ports to keep the system clean and organized, and to make future upgrades easy. I also wanted all the options in CS 4.0.9 to work with minimal customization of the scripts, so if I ever update to the next version, I don’t have to worry about overwriting files that are heavily customized. This guide is for the user who can’t get Clip-Share to work on a FreeBSD 6.3 system. Basic understanding of the operating system is required to follow this guide.

My installation guide works with the following installs:

FreeBSD 6.3, Apache 1.3.41, PHP 5.2.6, MySQL 5.0.51a
Mplayer (mplayer-0.99.11_7)
Mencoder 1.0rc1 (compiled from sources)
FFMPEG (ffmpeg-2008.07.27_7)

You will need root access to perform certain functions in this guide. If all the binaries are already installed for you, you might want to skip down a section or two and probably go to the convert.php file modification part.

While I have tried to simplify and remove unnecessary steps from this guide, I might become a bit redundant during the ports install. I have listed all the ports that you will need to install. Sometimes, installing one port (e.g. Mplayer) might install everything else for you automatically. Chances are that x264, xvid, speex, libtheora, faac, win32codecs, lame, etc. will all be compiled & installed for you as they can be dependencies (if selected during the configure step).

Just so you know, there is no need for ffmpeg-PHP or phpVideoToolkit. Lastly, you can follow this guide whether or not you have DirectAdmin or any other control panel installed.


First, let’s do some basic httpd.conf configuration. Open up your domain’s httpd.conf file (or global httpd.conf) and find the VirtualHost section for the domain you’re installing Clip-Share on. You will have to insert the following lines between the <VirtualHost></VirtualHost> directives of your domain.

DirectAdmin users: login as Admin, go to “Custom HTTPD Configurations”. Select the domain you are installing Clip-Share on. Add the following lines in the top box (“Httpd.conf Customization for yourdomain.com”).

php_value upload_max_filesize 100M
php_value post_max_size 100M
php_value max_execution_time 1000
php_value session.gc_maxlifetime 14000
php_value output_buffering on
php_admin_value suhosin.executor.func.whitelist exec //if using suhosin

Ports, Binaries & Sources

Using your favourite SSH client (putty, SecureCRT, direct console access, etc.) login to your server as root.

While this is not required, I put this setting in make.conf to prevent any of the ports from installing X11 garbage. There is no place for X11 or GUIs on a web server, so this little setting enforces the rule.

In /etc/make.conf, put:


Now, we get to install the necessary applications and libraries via Ports. Before you actually start installing everything, make sure your ports system is up to date. If you don’t know how to do this, check the FreeBSD handbook, section CVS.

Installing ports is very straight-forward and fun.

  • Install GD Library 2: cd /usr/ports/graphics/gd && make install clean
  • Install Flvtool++: cd /usr/ports/multimedia/flvtool++ && make install clean
  • Install lame: cd /usr/ports/audio/lame && make install clean
  • Install libogg: cd /usr/ports/audio/libogg && make install clean
  • Install libvorbis: cd /usr/ports/audio/libvorbis && make install clean
  • Install GCC 4.2 (for proper FFMPEG compilation): cd /usr/ports/lang/gcc42/ && make install clean
    Note: this may take a few minutes, as compiling GCC 4.2 takes a while.
  • Install FFMPEG: cd /usr/ports/multimedia/ffmpeg && make USE_GCC=4.2 install clean
    Note the USE_GCC=4.2 argument to enforce compiling of FFMPEG with a more recent version of GCC.
  • Install Mplayer: cd /usr/ports/multimedia/mplayer && make install clean
    (make sure to disable X11 stuff and select the codecs you want to support)
  • Install Mencoder: The one from ports is version 1.0rc1 (which doesn’t work well). We’re going to compile this binary from source instead.As root, do the following at the console:
    # wget http://www.mplayerhq.hu/MPlayer/releases/MPlayer-1.0rc1.tar.bz2
    # tar zxvf MPlayer-1.0rc1.tar.bz2
    # cd MPlayer-1.0rc1
    # ./configure
    # gmake 

    Next, we’re going to copy the compiled binary to /usr/local/bin/. Just type:
    # cp mencoder /usr/local/bin/

We need to do a small tweak to get things running smoothly. Flvtool++ installs itself under /usr/local/bin/, while Clip-Share looks for this utility under /usr/bin/ (beats me as to why). Rather than have duplicate binaries, we’ll create a symlink. Just do the following (as root):

# cd /usr/bin/
# ln –s flvtool2 /usr/local/bin/flvtool++

Upload Clip-Share Files

Now it’s time to go ahead and upload the Clip-Share files. Don’t forget to transfer the files in Binary mode (as recommended by the developers).

Make sure the .htaccess file is uploaded correctly and that it’s present in the root directory of your website. On an OSX workstation, you won’t see this file as Leopard hides files that begin with a dot. Your best bet is to upload the entire Clip-Share archive file and extract it via console, this way making sure all the files are uploaded correctly and are present.

Make sure the CGI-BIN directory is chmod’ed 755, and both the user AND the group belong to YOUR username on the server. Double-check this now; it’ll take you 30 seconds and save you a lot of trouble. If it is different, do the following via the console:

# chown username:username cgi-bin

Where username is your login name on the server.

Follow the rest of the CS installation file. Change the absolute path in ubr_upload.pl accordingly and verify that it is correct. On a FreeBSD system with DirectAdmin installed, it’ll look like: /home/username/domains/yourdomain.com/public_html/

Changes to Script Files

Modify the convert.php script as follows:

*** Removed previous $encodecommand changes as we’re working with Mencoder 1.0rc1 now. ***

exec($config[‘metainject’]. ‘ –Uv ‘ .$config[‘FLVDO_DIR’]. ‘/’ .$vid. ‘x.flv ‘ .$config[‘FLVDO_DIR’]. ‘/’ .$vid. ‘.flv’);

exec($config[‘metainject’]. ‘ ‘ .$config[‘FLVDO_DIR’]. ‘/’ .$vid. ‘x.flv ‘ .$config[‘FLVDO_DIR’]. ‘/’ .$vid. ‘.flv’);

Testing, Verification and Miscellaneous Configuration

Login to your website’s administration panel (/siteadmin) and go to “System Checks”. Make sure there are no binaries missing, other than THEORA and FAAC support.

Go to “Media Settings” and enable “Video resize” if you want.

Upload several test videos of varying sizes and formats. Make sure the audio is in sync and that Clip-Share is resizing them accordingly. Take a look at your server load and see if everything is looking ok. The videos you upload must be error-free and encoded properly. I’ve noticed that videos that are poorly encoded or corrupt won’t convert correctly.

Pay attention to Apache error log file in case something goes wrong. If you get “No file given” errors, it’s related to Mencoder from my experience. Make sure you have 1.0rc1 or 1.0rc2 installed and nothing else.

I hope this guide helps someone out. Feedback is much appreciated. Enjoy!

DirectAdmin 1.31.0, PHP 5.2.3 and CakePHP

Here’s an interesting problem I came across just now. I was setting up a new domain with CakePHP and noticed that the stock copy did not run, neither did identical files I copied from another working domain. Before this, each time I uploaded CakePHP to my server, everything ran out of the box, so why not now? It’s been a while since I’ve added a new domain to the system, so right away I thought it must be PHP or DirectAdmin causing the problem (they were the latest updates done to the server). The error message I was getting from CakePHP was the following:

Warning: session_start() [function.session-start]: open_basedir restriction in effect. File(/var/tmp/) is not within the allowed path(s): (/home/user/:/tmp:/usr/local/lib/php/) in /home/user/domains/domain.com/public_html/cake/libs/session.php on line 154

Fatal error: session_start() [<a href=’function.session-start’>function.session-start</a>]: Failed to initialize storage module: files (path: ) in /home/user/domains/domain.com/public_html/cake/libs/session.php on line 154

Doing a quick check on Google brought some insight to the matter, but nothing concrete. I decided to check phpinfo() and see what the open_basedir restriction was set to. Since I had a copy of phpinfo() on another domain of mine, the result of open_basedir came up to “no value”. I mumbled “WTF” to myself and was totally puzzled. Now, quick note on my mistake here: always run phpinfo() on the same user and domain that you are trying to troubleshoot. Fortunately, I didn’t give up just yet: I ran phpinfo() on the troubleshooting domain and right away notice that open_basedir had values, none of which would work with CakePHP. Finally, something! So where were these values coming from?

The next step was to check Apache’s httpd.conf. Since DirectAdmin organizes the httpd.conf files of every user account seperate (it Includes user-httpd.conf at the end of the main httpd.conf file) I went to the troubling user’s configuration and scrolled all the way to the bottom to the latest added domain. Bingo! It had the following line added:

php_admin_value open_basedir /home/user/:/tmp:/usr/local/lib/php/

And it was the only domain that had that line too. A quick sigh of relief after, I silently commented that line out and crossed my fingers, restarted Apache, refreshed the homepage and… yep, everything worked as usual. It seems that the latest version of DirectAdmin (1.31.0 at the time of this writing) has some extra security features enabled (which is a good thing) but a bit unnecessary for people who run their sites on their own servers. So, this is a heads up for everyone out there that might come across this error one day and not know what to do. I hope it works for you.

Update: DirectAdmin actually has a built-in control panel feature that allows you to turn on/off open_basedir restrictions and PHP safemodes per domain name. Just go to the control panel main page and click on PHP Safemode Configuration (available as of 1.31.4, maybe earlier).