starting ./directadmin - libmysqlclient.so.16 problem


I don't know if there is something different based on platform (I'm using Debian 6 x64) or just something wrong with that file hosted by DA, but when I tried using the file from http://files.directadmin.com/services/debian_6.0/libmysqlclient.so.16 it didn't work. I had to pull the libmysqlclient.so.16 file out of the following location on my system to get things to work:
/usr/local/mysql-5.5.9-linux2.6-x86_64/lib/libmysqlclient.so.16

Just FYI, the files ARE different in size, so for whatever reason the one hosted by DA didn't work whereas the one in the above location did. Maybe the one hosted at DA for Debian 6 is only for 32bit platforms. If that's the case then I guess the 64bit version needs to be hosted as well.

For a more detailed thread on trying to get to the bottom of problems specifically in Debian 6.0 x64 (including this one) see http://directadmin.com/forum/showthread.php?t=41529
 
Last edited:
Hello,

The linking really shouldn't be needed. It usually means that something else is out of place.

1) Check your Clients Section to ensure the OS set for your license matches the OS that you're using.
Related: http://help.directadmin.com/item.php?id=318

2) Use the default values for the install to avoid these types of issue (as installing older versions of mysql can also cause linking issues, as DA is linked against the default version set in the install pack)

3) Check your binaries (once running/fixed):
Code:
cd /usr/local/directadmin
./directadmin o
John
 
Hello,

The linking really shouldn't be needed. It usually means that something else is out of place.

1) Check your Clients Section to ensure the OS set for your license matches the OS that you're using.
Related: http://help.directadmin.com/item.php?id=318

2) Use the default values for the install to avoid these types of issue (as installing older versions of mysql can also cause linking issues, as DA is linked against the default version set in the install pack)

3) Check your binaries (once running/fixed):
Code:
cd /usr/local/directadmin
./directadmin o
John

But there isn't anything "out of place" in my system. I have the correct OS set on my license as "Debian 6 64" and I'm only changing a couple settings in options.conf (certainly nothing crazy). Please see http://www.directadmin.com/forum/showthread.php?t=41529 for a list of things I've encountered on a clean Debian 6 x64 install.

To make sure I'm crystal clear about all this, here is my process from start to finish:

1) Install Debian 6 x64 with debian-6.0.2.1-amd64-i386-netinst.iso
2) Update Apt repository
Code:
aptitude update
3) Per DA installation guide, install the following:
Code:
aptitude install gcc g++ make flex bison openssl libssl-dev perl perl-base perl-modules libperl-dev libaio1 libaio-dev

At this point the system is running perfectly. There are no errors or warnings running aptitude and no packages are listed as broken. Now to install DA.

4)
Code:
cd /root
wget http://www.directadmin.com/setup.sh
chmod 755 setup.sh
5) In order to get DA to use my pre-made options.conf from the start (as others have in the forums) and to set a couple of custom config files, run the following:
Code:
mkdir /usr/local/directadmin/
mkdir /usr/local/directadmin/custombuild/
mkdir /usr/local/directadmin/custombuild/custom/
mkdir /usr/local/directadmin/custombuild/custom/phpmyadmin/
wget -O /usr/local/directadmin/custombuild/custom/phpmyadmin/config.inc.php <external location of php config file>
wget -O /usr/local/directadmin/custombuild/options.conf <external location of options.conf>
chmod 644 /usr/local/directadmin/custombuild/custom/phpmyadmin/config.inc.php
chmod 644 /usr/local/directadmin/custombuild/options.conf
echo 1.2 > /root/.custombuild
/root/setup.sh <userid> <licenseid> hostname eth0 <ip>

Here is my options.conf file for review:
Code:
#PHP settings. default_php possible values - 5 or 6, php5_ver - 5.2 or 5.3
default_php=5
php5_ver=5.3
php5_cli=yes
php5_cgi=no
php6_cli=no
php6_cgi=no
php_ini=yes
#Possible values - recommended or dist
php_ini_type=recommended
zend=no

#Possible values - 5.0, 5.1, 5.5
mysql=5.5
mysql_inst=yes
mysql_backup=yes

#Possible values - 1.3, 2.0 or 2.2
apache_ver=2.2

#Web applications
phpmyadmin=yes
atmail=no
squirrelmail=no
roundcube=no
uebimiau=no

#Mail options
exim=no
spamassassin=no
mail-header-patch=yes
dovecot=no
eximconf=no

#Statistics
awstats=no
webalizer=yes

#FTP options
proftpd=no
pureftpd=yes

#Jailed shell
jail=no

#Custombuild options
custombuild=1.2
autover=yes
bold=yes
clean=yes
cleanapache=yes
clean_old_tarballs=no
clean_old_webapps=yes
downloadserver=files.directadmin.com

#Cron settings
cron=no
email=<email address removed>
notifications=yes
da_autoupdate=no
updates=no
webapps_updates=yes

clamav=no
mailman=no
ioncube=no
mysql_backup_dir=/usr/local/directadmin/custombuild/mysql_backups
autoconf=yes
automake=yes
libtool=yes

At this point, DA is NOT fully installed because it is looking for libmysqlclient.so.16 but Custombuild installed libmysqlclient.so.18 as part of MySQL 5.5.15. Because of this, I then have to do the following:

6)
Code:
cd /usr/local/mysql/lib
rm -f libmysqlclient.so.16
cp /usr/local/mysql-5.5.9-linux2.6-x86_64/lib/libmysqlclient.so.16 /usr/local/mysql/lib/libmysqlclient.so.16
chmod 755 libmysqlclient.so.16
ldconfig

7) Now that the old library is there, we re-run DA setup
Code:
/root/setup.sh <userid> <licenseid> hostname eth0 <ip>

Ok, so now DA is installed, but there are still the other issues. As you can see from my options.conf file, Exim has been set as "no", but the already installed Exim in Debian is now broken (see the other thread I mentioned earlier for details). Also, the libz issue is present and must be resolved (also mentioned in the other thread).

Please advise.
 
Try it with all default install options (don't specify anything for custombuild). The likely cause is:
Code:
mysql_inst=yes
which is not a default option. Worry about installing a different copy of mysql after.

I do now recall needing to run some re-linking code in the update.sh for debian when DA is being updated.
After the install, try:
Code:
cd /usr/local/directadmin/scripts
./update.sh
which does a few checks on lib 16 vs 18. If you want to check the code, it's at the bottom of the update.sh, then finish with the "./directadmin i; ./directadmin p;"

This is likely the same as what you were running anyway, in which case, it would be a bug, and would need to be added to the installer, instead of just the updater. But this only applies to the case where mysql is updated before DA is installed (which should be allowed).

Snip from the update.sh:
PHP:
#debian if MySQL 5.5.11+
#april 21, 2011
if [ -e /etc/debian_version ]; then
                        if [ -e /usr/local/directadmin/directadmin ]; then
                                COUNT=`ldd /usr/local/directadmin/directadmin | grep -c libmysqlclient.so.16`
                                if [ "${COUNT}" -eq 1 ]; then
                                        if [ ! -e /usr/local/mysql/lib/libmysqlclient.so.16 ] && [ -e /usr/local/mysql/lib/libmysqlclient.so.18 ]; then
                                                echo "*** Linking libmysqlclient.so.16 to libmysqlclient.so.18";
                                                ln -s libmysqlclient.so.18 /usr/local/mysql/lib/libmysqlclient.so.16
                                                ldconfig
                                        fi
                                fi
                                COUNT=`ldd /usr/local/directadmin/directadmin | grep -c libmysqlclient.so.18`
                                if [ "${COUNT}" -eq 1 ]; then
                                        if [ ! -e /usr/local/mysql/lib/libmysqlclient.so.18 ] && [ -e /usr/local/mysql/lib/libmysqlclient.so.16 ]; then
                                                echo "*** Linking libmysqlclient.so.18 to libmysqlclient.so.16";
                                                ln -s libmysqlclient.so.16 /usr/local/mysql/lib/libmysqlclient.so.18
                                                ldconfig
                                        fi
                                fi
                        fi
fi
John
 
Try it with all default install options (don't specify anything for custombuild).

Thanks for your suggestions John.

I've been experimenting a bit over the past couple days with the install scripts and I think I've come across a bug that explains the Exim issue I've been having. I can't find any place in the initial install scripts that is ever checking the exim setting in options.conf. It is trying to uninstall Exim and then compiling and reinstalling no matter what the options.conf setting is. Note that the build script (for updating) does seem to check the setting, but an initial install is hosing the distribution's existing Exim installation. Can you look into this?

On a lesser note, it looks like it is also trying to install GD with "apt-get -y install gd" (which doesn't exist) rather than "apt-get -y install libgd2-xpm".

Thanks.
 
Hello,
It is trying to uninstall Exim and then compiling and reinstalling no matter what the options.conf setting is.
1) I'm not seeing that... Note that custombuild isn't the main installer for exim. The main spot that exim is installed is:
/usr/local/directadmin/scripts/exim.sh

using the package in:
/usr/local/directadmin/scripts/packages

The custombuild default for exim is no, and I've not heard of any issues where "build" is ignoring the options.conf value... perhaps I'm missing something. Exim in custombuild is for version updates. The exim.sh is for the initial install, so the exim.sh will always happen. Using "no" in custombuild just means you don't want custombuild to update it. It will always be install anyway.

2) The apt-get gd install attempt can likely be ignored, as it's more for other OS's.
The script uses "gd" as a universal name/index. Other items are named correctly, but I dont think the missing gd module is hurting anything.

John
 
Hello,1) I'm not seeing that... Note that custombuild isn't the main installer for exim. The main spot that exim is installed is:
/usr/local/directadmin/scripts/exim.sh

using the package in:
/usr/local/directadmin/scripts/packages

The custombuild default for exim is no, and I've not heard of any issues where "build" is ignoring the options.conf value... perhaps I'm missing something. Exim in custombuild is for version updates. The exim.sh is for the initial install, so the exim.sh will always happen. Using "no" in custombuild just means you don't want custombuild to update it. It will always be install anyway.

I guess I'm just a little confused because, when you install DirectAdmin, you choose between Custombuild and CustomApache, so it seemed logical to think that the initial installer would follow the same options.conf settings.

Regardless, can you list any specific reasons that Exim needs to be compiled and installed by your script during a DA installation? Are there some special features that the pre-installed Exim from Debian doesn't provide? Since I'm not using my DA box for any email functionality except for scripts that need an outgoing mailserver it seems to me like the existing Exim install would work fine. Just one less thing that I need to maintain apart from the distribution's package management.

Thanks for any insight into the issue. I'm not opposed to manually editing the installer script myself (I've already tested several changes), but then I'd have to re-edit it every time you update the script if I want to install on a clean machine again.
 
Hello,
can you list any specific reasons that Exim needs to be compiled and installed by your script during a DA installation?
The only reason you'd use custombuild for exim is to update to a new version where applicable. Doing it during the actual install isn't usually recommended (leave it as "no")since we already include binaries which should work fine, are installed already anyway, and exim is one of the more difficult packages to compile due to it's dependencies (usually takes a few tries to meet it's specific needs)... any failure on the first try aborts the whole DA install.. hence best to do it after everything else is done, and only if you need to.

The debian packages likely do have all required features that DA needs (mainly just the perl option), however, what it doesn't have is the same compile settings for things like log names and uid/gid values for the spool directory (I believe it uses "exim" while we use "mail"). So the pre-installed package tends to not match up completely.

John
 
Going back to the main point of this thread (which is the libmysqlclient problem), I just saw in the DA changelog the following entry:
http://www.directadmin.com/features.php?id=1232

This explains that DA has been updated to not link to any MySQL libraries at compile time for the CentOS 5 x64 platform. This is exactly the same issue that many of us have experienced with various versions of Debian (mine being Debian 6.0 x64). Can this not be done for Debian as well?
 
Back
Top