We were able to install DirectAdmin (a Web hosting control panel) on Amazon’s Elastic Compute Cloud, branded as EC2. We would like to share the steps required to build a working instance of DirectAdmin on an Amazon server. First, I would like to personally thank Mark from DirectAdmin for being so accommodating and granting us a trial license. His help is very much appreciated! Keep in mind that UNIXY‘s truly fully managed service goes above and beyond. We take business dreams and make them a reality.

Before we list the requirements, it is important to note that EC2 instances are Xen Virtual Machines. We encountered some issues running DA on the “Small” Amazon instances. The issues are related to 64-bit mode library mismatches. The only instances to be able to run DirectAdmin out of the box are of type “Large” and better. They are more expensive but ideal for this configuration.

Here are the requirements:

• Instance of type Large
• Linux CentOS 5 image
• One elastic (which is another word for static) IP address

Go ahead and bring up the node as you would normally do. Be sure to remove all extra software that comes pre-installed with the CentOS 5 image. Otherwise, it will break DirectAdmin. If in doubt, follow the instructions on the DirectAdmin Install page:

http://www.directadmin.com/install.html

Once logged in as root, go ahead and download the DirectAdmin install tarball:

# wget http://www.directadmin.com/setup.sh

By default, the licensing scheme of DirectAdmin makes it that setup.sh binds to the licensed IP address. Here’s how the license verification command looks like:

$BIN_DIR/wget $WGET_OPTION -O $DA_PATH/update.tar.gz –bind-address=$IP https://www.directadmin.com/cgi-bin/daupdate?uid=$CID\&lid=$LID

But as you know, EC2 instances are 1:1 private:public NAT. Which means that the license check step will fail and the DA install won’t start. To avoid this chicken-and-egg problem, we are going to tell setup.sh to not bind to any IP address but to simply connect to the DA licensing server using the elastic external IP address, which it will do by default. Go ahead and run this command against the setup.sh file:

# sed -i 's/--bind-address=\$IP//;' setup.sh

Before we run setup.sh, we need to trick the setup script to think that the external IP address is “attached” to the server. Here’s how:

# ifconfig eth0:0 inet 1.1.1.1 netmask 255.255.255.255 up

Be sure to replace the IP address 1.1.1.1 with your elastic IP. Then simply run setup.sh:

# cd /usr/local/directadmin/scripts; while [ true ]; do sed -i 's/--bind-address=\$IP//; s/--bind-address=\${3}//;' *.sh > /dev/null > 2&>1; sleep 10; done & sh setup.sh 11111 22222 vpslux.com eth0:0 1.1.1.1

Woaah! Wait a minute! What is that!? OK, let’s break it down. The DA scripts directory gets unpacked into the server after you run setup.sh. It dumps a list of scripts that are used by DA to setup accounts, domains, etc. Some scripts use the same –bind-address flag. Having that flag in those scripts breaks DA. the one-line script “while [ true ]; do sed -i ‘s/–bind-address=\$IP//; s/–bind-address=\${3}//;’ *.sh; sleep 10; done” simply goes to that directory and removes the flag.

The trick being DA attempts to run some of those scripts while setup.sh is running. So it’s important to have the sed script run in parallel during the installation. Once the setup.sh is done running, we’ll kill the job (or reboot per the final step). The arguments supplied to setup.sh are in this format

# setup.sh <ClientID> <LicenseID> <Hostname> <Interface> <ExternalIP>

Be sure to replace those values accordingly. Once the install finishes, simply reboot the VM:

# reboot

That’s all folks. Enjoy!

If you attempt to store a file larger than roughly 5GB, the Amazon service will generate the following error and fail to store the file:

<Error><Code>EntityTooLarge</Code><Message>Your proposed upload exceeds the maximum allowed object size</Message><ProposedSize>6091682399</ProposedSize><MaxSizeAllowed>5368709120</MaxSizeAllowed></Error>

One way around this limitation is use the GNU/Linux command split to divide the file into several smaller chunks, which are in turn stored in Amazon’s S3. It’s important to know the order of these chunks as the original file is split. The good news is that the split command preserves the order of the chunks by adding a suffix to each chunk. Here’s an example of the split command in action. In this example, we’re splitting file outfile.tmp, which is of size 2.3GB, into chunks of 1GB each:

# du -sh outfile.tmp
2.3G    outfile.tmp

# split -a 1 -b 1073741824 outfile.tmp outfile.tmp.

# ls -alh outfile.tmp.*
-rw-r–r– 1 root root 1.0G Apr 11 09:51 outfile.tmp.a
-rw-r–r– 1 root root 1.0G Apr 11 09:51 outfile.tmp.b
-rw-r–r– 1 root root 274M Apr 11 09:51 outfile.tmp.c

As you can see, split is appending alphabetical letters to the end of the split file name. This comes handy when reassembling the file. Here’s a quick proof of concept following our earlier example:

# md5sum outfile.tmp
e1f4bbcfc2309b3c7ea48028c3f1c9e9 outfile.tmp
# cat outfile.tmp.a outfile.tmp.b outfile.tmp.c > reassembled.tmp
# md5sum reassembled.tmp
e1f4bbcfc2309b3c7ea48028c3f1c9e9 reassembled.tmp

All as planned! That’s all folks.

A customer wanted Amazon’s S3 tools installed on his Centos 5.3 server in order to backup important files off-network. The task is straight forward as it requires installing the usual Ruby interpreter, tools, and Gems. But as it turned out, cPanel appends an exclude line in /etc/yum.conf to prevent installing anything related to Ruby:

exclude=apache* bind-chroot courier* dovecot* exim* httpd* mod_ssl* mysql* nsd* perl* php* proftpd* pure-ftpd* ruby* spamassassin* squirrelmail*

I’m reluctant to un-exclude the ruby* entry as it could somehow break the cPanel production install. The next logical thing to do in this case is to scan /scripts for anything ruby related:

[/scripts]# ls -1|grep -i ruby
installruby*

Bingo! The cPanel conformant way of installing Ruby is to run /scripts/installruby. But it’s important to read cPanel’s document on RoR just in case. Here’s the URL:

http://www.cpanel.net/docs/ror/index.html

I then simply ran the script to install Ruby and configure S3 to keep the customer happy! I hope this will help someone carry on the Ruby installation.