Category Archives: direct admin

Another cheap rack of compute power

I think it was about 1 year ago that I setup a rack at a datacenter, filled with servers that had come off lease. You can get them cheap, real cheap vs. a new server.

I read the other day that Intel has not made any ‘major’ improvements to their processors since 2011. Sure there have been some improvements to SATA, SSD’s etc. But when you can buy a server for 10% – 20% of the price of purchasing new, new just does not seem worthwhile.

Last year we used 1U twin Supermicro servers using the the X7DWT-INF motherboard. They came equipped with 2x Intel Xeon L5420 quad core processors and 16GB ram. I looked up the price paid last year, they were $450.

They work fine, way more ram than we need. The only downside is the IPMI management is not always the greatest but we have managed. We even bought extra servers that just sit in the rack, to be used as parts in the event of a failure of any of the old servers. So far the parts machines are just sitting there, no issues with parts.

Now 2015, we want to build another rack – at another datacenter (additional redundancy). Would like to find computers with X8 based motherboards as the IPMI is supposed to be better.

Unfortunately they are still too costly, so we are looking at the exact same model of server that we bought last year. The good news is the price has dropped for $450 per 1U down to $250. Imagine, there are two full servers in 1U for $250. That is really $125 per server, since there are two per 1U. Simply blows my mind, since a new machine would cost you $2,000+ for a server and you don’t get anywhere near the price/performance boost.

Say we put 45 1U units in a rack (that is 90 servers) for a cost without hard drives of $11,250. If we could find new servers, twin models for $2000 (without hard drives) the cost would be $90,000. I doubt you could find servers for $2000 new.

There are no hard drives included with the servers, so SSD will be purchased for most.

A couple servers will be used as database servers, last year we used WD Red drives and attempted to implement read caching using Fusion-IO cards. The caching concept did not work very well, the performance improvement seen was not worth the effort.

Seagate Laptop SSHDSo this year, rather than WD Red (currently $69.99) we are going to try using Seagate Laptop SSHD (currently $79.68).

Now according to benchmarks over at UserBenchmark these 2.5 inch drives do not perform well vs. 3.5 inch drives or SSD (of course). However, if you benchmark them WD Red 2.5 vs Seagate Laptop SSHD they actually perform 58% better overall than WD Red and 161% better on 4K random writes.

Since the workload on the database servers are 90% write, we are going to give these laptop drives a chance.

We still have a Fusion-IO card sitting here unused as well from last year. So we can stick that in one of the DB servers to increase the read side of things. Would not go out and buy one just for this purpose but since it is just sitting here on the shelf, might as well put it in.

LDAP / memcache frustration on DirectAdmin

I have about 5 servers that I maintain to run websites. In addition to the base system that DirectAdmin installs I have a requirement for a few additional modules.

These are memcache and LDAP.

I use Debian x64 and DirectAdmin, to try and keep things the same. So if it works on one, you test it on one… it should work on the others right?

Every time I upgrade PHP I have issues getting these two modules compiled back in (add custom modules).

I upgraded one server to PHP 5.6.8, using CustomBuild 2.0 I enabled LDAP. So my custom/ap2/configure.php56 looks like this, to add LDAP:

./configure \
        --with-apxs2 \
        --with-config-file-scan-dir=/usr/local/lib/php.conf.d \
        --with-curl=/usr/local/lib \
        --with-gd \
        --enable-gd-native-ttf \
        --with-gettext \
        --with-jpeg-dir=/usr/local/lib \
        --with-freetype-dir=/usr/local/lib \
        --with-libxml-dir=/usr/local/lib \
        --with-kerberos \
        --with-openssl \
        --with-mcrypt \
        --with-mhash \
        --with-ldap \
        --with-mysql=mysqlnd \
        --with-mysql-sock=/tmp/mysql.sock \
        --with-mysqli=mysqlnd \
        --with-pcre-regex=/usr/local \
        --with-pdo-mysql=mysqlnd \
        --with-pear \
        --with-png-dir=/usr/local/lib \
        --with-xsl \
        --with-zlib \
        --with-zlib-dir=/usr/local/lib \
        --enable-zip \
        --with-iconv=/usr/local \
        --enable-bcmath \
        --enable-calendar \
        --enable-ftp \
        --enable-sockets \
        --enable-soap \
        --enable-mbstring \
        --with-icu-dir=/usr/local/icu \

Great, it works. LDAP is compiled in and everyone is happy.

I go and do the upgrade on the next server, no luck. The compiler for PHP says it can’t find the LDAP files. I check what ldap modules are installed on both machines with this:

dpkg-query -l '*ldap*'

Both machines show different results, the packages are mostly the same, but not exact. In fact the output of the dpkg-query is not the same, one shows an Architecture column and one does not. Hmmm… is one 64 bit and the other 32… checking on that… nope, both are 64 bit.

In the end on the machine with the issue where it says it can’t find the LDAP files I created a symlink to a ldap file I found.

ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib/

That was enough that it could compile and things seem to be working, but super frustrating that there are so many differences on machines where I try and keep things the same.

To have DirectAdmin monitor the status of the memecached instance you can add it to /usr/local/directadmin/data/admin/services.status and DirectAdmin will start/restart if necessary.

The DA guys document it here:

apt-config: /usr/local/lib/ no version information available (required by /usr/lib/

I get an email daily from cron on a few of my directadmin servers. No idea what it means or what that cron job is even supposed to be doing.

After searching around on the net there are a lot of people with the same issue.

Some of the suggested fixes do not sound very nice, like making some hacks to custombuild and then rebuilding every piece of software on the system. That simply sounds dangerous!

I found this blog post where the author deletes multiple copies that exist on his system and then create link to the correct version.

That sounded not so dangerous so I gave it a try and it worked. In my case I only had /usr/local/lib/ not /usr/local/lib/ so my solution looked more like this.

rm /usr/local/lib/
ln -s /usr/lib/ /usr/local/lib/

Compiling DNSDB Exim on Debian Wheezy Directadmin

About 1.5 years ago I did a posting with easy instructions to compile in a custom build of Exim on Directadmin.

Since then I upgraded to Debian Wheezy and Exim has been upgraded to 4.84. The step-by-step instructions don’t work anymore as a result.

Here is an updated version of those instructions.

First, ensure you have the required dependencies.

apt-get install libdb5.1-dev libperl-dev libsasl2-dev

Change all occurrences of 4.84 to the version you want to use. The sample pulls Exim from some mirror, you might need to lookup a working URL to a mirror if this one goes down.

tar xvzf exim-4.84.tar.gz
cd exim-4.84/Local
perl -pi -e 's/^EXTRALIBS/#EXTRALIBS/' Makefile
perl -pi -e 's/HAVE_ICONV=yes/HAVE_ICONV=no/' Makefile
perl -pi -e 's/^#LOOKUP_DNSDB=yes/LOOKUP_DNSDB=yes/' Makefile
cd ..
make install

The above commands will download the unmodified source for exim, extract it, download a makefile from the directadmin servers, use a perl command to adjust the makefile, compile and install the fresh exim build.

The file that is created is /usr/sbin/exim-4.84-1, so we must change the name and overwrite the existing exim file.

/etc/init.d/exim stop
cp -f /usr/sbin/exim-4.84-1 /usr/sbin/exim
chmod 4755 /usr/sbin/exim
/etc/init.d/exim start

To verify you have a working Exim with DNSDB compiled in do the following:

exim -bV

Exim 4.84

PHP 5.3 still shipping with DirectAdmin

PHPI don’t know why but DirectAdmin still rolls out with PHP 5.3 which was released in June 2009. It is now June 2014, how about an upgrade?

You might not want to jump to PHP 5.5 because it deprecates a bunch of the ‘old way’ of connecting to mySQL.

But is it safe to move to 5.4? If you want to find out and are running DirectAdmin, you can update with custom build like this:

cd /usr/local/directadmin/custombuild
./build update
./build set php5_ver 5.4
./build php n

Is your system still going to work? Guess you will have to upgrade and find out.

If you had installed any extensions that you compiled, odds are good they will no longer function because they were compiled for another version.

I ended up having to redo LDAP (which I compiled right in) and I had to redo APC and memcache as those were broken as a result of the PHP version upgrade.

To quickly fix memcache I just did the following to commands

pecl uninstall memcache
pecl install memcache

SSL & Server Name Indication

I recently put a request in to one of the datacenters where I have servers for an additional IP address. Of course they ask what is it for?

An SSL website was the reply…

I got back a note that we do not provide additional IP addresses for SSL anymore.


So there must now be a common way to put SSL on a shared IP, news to me.

Turns out it is called Server Name Indication which allows the hostname of the request to be included in the SSL handshake.

Turns out you can do it with DirectAdmin can do it, with a bit of tweaking. Looks like I will be putting SNI on my list of things to test.

PHP Magic Quotes – A Thing Of The Past

I’ve got a few DirectAdmin servers running, anytime someone inserts data into the database I either escape the incoming data or use parametrized sql (better way).

If you find you insert something like Mr’Toad and you end up with Mr\’Toad on your screen you probably have one or more of PHP magic quotes enabled. Check your php.ini file and if you have one or more enabled turn them off.

A lot of systems will no longer run if they are enabled and as of PHP 5.3 they are DEPRECATED. If you happen to be using PHP 5.4 you will find they are totally REMOVED so don’t rely on them!

You will want to ensure you have lines in your php.ini showing they are off:

; Magic quotes are a preprocessing feature of PHP where PHP will attempt to
; escape any character sequences in GET, POST, COOKIE and ENV data which might
; otherwise corrupt data being placed in resources such as databases before
; making that data available to you. Because of character encoding issues and
; non-standard SQL implementations across many databases, it’s not currently
; possible for this feature to be 100% accurate. PHP’s default behavior is to
; enable the feature. We strongly recommend you use the escaping mechanisms
; designed specifically for the database your using instead of relying on this
; feature. Also note, this feature has been deprecated as of PHP 5.3.0 and is
; scheduled removed in PHP 5.4.
; Default Value: On
; Development Value: Off
; Production Value: Off
magic_quotes_gpc = Off

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = Off

; Use Sybase-style magic quotes (escape ‘ with ” instead of \’).
magic_quotes_sybase = Off

If you have any doubts about your system settings, check phpinfo();

DirectAdmin – Missing PHP LDAP

If you have found yourself needing to access an LDAP server from PHP and your running on a DirectAdmin box you’re going to find it is not available by default.

Here is what I needed to do in order to get it running on a Debian system:

apt-get install php5-ldap libldap-dev

Copy the file into the PHP extensions directory:

cp /usr/lib/php5/20090626/ /usr/local/lib/php/extensions/no-debug-non-zts-20090626/

Add the extension to your active php.ini file, in my case the active php.ini file was: /usr/local/lib/php.ini. You can find out the location of your working php.ini file through phpinfo().

Restart Apache and you should be up and running (you can use phpinfo() to check if LDAP is available to you.

/etc/init.d/httpd restart

DirectAdmin – Root Email Messages

When you setup DirectAdmin, notification messages are by default sent to  For most people this would not be practical.

To easily modify where all messages to root are sent, the easiest is to create a .forward file for the root user.

Execute the following command and messages to will automatically be forwarded to your actual email address and hey, you might actually get them that way.

echo "" > /root/.forward

In addition to that, you need to ensure the permissions are correct on the .forward file. If you are running Exim, it is really picky about the security level on the files by default.

I found this works:

chmod 0600 .forward

Compiling DNSDB into Exim on Debian/Directadmin

Directadmin by default uses Exim, however the DNSDB lookup module is not available. DNSDB allows Exim to perform DNS lookups as part of mail processing. I am using it to lookup SPF records of incoming mail.

Currently there is no way to add it, or enable it – not even using custombuild.  If you want it you must compile Exim from source.  Here is the procedure I used on a Debian box to get it activated.

First, ensure you have the dependencies for exim.

apt-get install libdb4.8-dev libperl-dev libsasl2-dev

Change all occurrences of 4.80.1 to the version you want to use.

tar xvzf exim-4.80.1.tar.gz
cd exim-4.80.1/Local
perl -pi -e 's/^EXTRALIBS/#EXTRALIBS/' Makefile
perl -pi -e 's/HAVE_ICONV=yes/HAVE_ICONV=no/' Makefile
perl -pi -e 's/^#LOOKUP_DNSDB=yes/LOOKUP_DNSDB=yes/' Makefile
cd ..
make install

The above commands will download the unmodified source for exim, extract it, download a makefile from the directadmin servers, use a perl command to adjust the makefile, compile and install the fresh exim build.

The file that is created is /usr/sbin/exim-4.80.1-1, so we must change the name and overwrite the existing exim file.

/etc/init.d/exim stop
cp -f /usr/sbin/exim-4.80.1-1 /usr/sbin/exim
chmod 4755 /usr/sbin/exim
/etc/init.d/exim start

To verify you have a working Exim with DNSDB compiled in do the following:

exim -bV

You should get an output from Exim, look for the line that lists the built-in lookups and confirm that dnsdb is listed (as seen in the image below).