View Full Version : DBI extremely out of date

05-28-2005, 07:40 PM
Just happened to notice that my pre-installed version of DBI is 1.13, released in 1999 (for the record, July 11).

Is this so far out of date because I've been with Westhost for that long, or does everybody on WH2.0 have DBI 1.13 as well?

05-29-2005, 02:04 PM
It wouldn't suprise me if that is still the default for everyone, but upgrading it shouldn't be terribly hard. I've never installed in my VPS and just went to http://search.cpan.org to find it. Then, from within SSH in my account, installed it as follows:

$ cd
$ mkdir src
$ cd src
$ wget http://search.cpan.org/CPAN/authors/id/T/TI/TIMB/DBI-1.48.tar.gz
$ tar -xzf DBI-1.48.tar.gz
$ cd DBI-1.48
$ perl Makefile.PL
$ make
$ make install

I would recommend uninstalling it from your Site Manger before upgrading it though. You also may need to install extra modules to get everything out of it that you want, but the above steps are pretty cut and dry for getting perl modules off of CPAN. You can also try just using the CPAN shell but I've only had limited success with using that compared to the above steps.

05-30-2005, 09:49 AM
Through Site Manager I removed "PerlMySQL 1.1" (is that just an arbitrary name for a collection of modules Westhost put together? I checked and that's definitely where DBI 1.13 comes from).

Then manually installed fresh copies of DBI (1.48) & the latest DBD::mysql

Problem now is DBD somehow picks up the mysql.sock path that MySQL was compiled with (/tmp/mysql.sock) rather than the /etc/my.cnf settings (/var/lib/mysql/mysql.sock).

I don't want to make a symlink in /tmp, & would rather not switch my.cnf to reference /tmp/mysql.sock since supposedly /tmp is less secure. I realize I can get around this by specifing either the socket path or my.cnf path in each DBI->connect call (or use TCP/IP to connect) but that sucks..

Compiling DBD, it seems like it gets the socket path setting from mysql_config (and it's documented that mysql_config ignores my.cnf settings) so I tried copying mysql_config to the DBD source dir, modified it to return the socket path I wanted & then I ran:

perl Makefile.PL --libs="-L/usr/local/mysql/lib -lmysqlclient -lz" --cflags=-I/usr/local/mysql/include --mysql_config="./mysql_config"

(and then 'make')

...no luck, make test still fails with /tmp/mysql.sock errors. Tried reinstalling MySQL through Site Manager just in case Westhost had changed the socket path compile setting from /tmp to /var/lib/mysql/ but no dice.

Any suggestions other than compiling MySQL manually? There's gotta be a way to hack the DBD install so it compiles with the correct socket path..

05-30-2005, 01:44 PM
If I get a chance today I'll play around with it. One thing to keep in mind is your VPS is a single user environment so you can get away with just living with the mysql.sock in /tmp. One might call it cheating, or perhaps 'adapting to your environment'. But whichever place you place your mysql.sock doesn't matter--it is effectively the same because everything runs as your user.

05-30-2005, 03:58 PM
Doh, good point about /tmp ..

I looked around more & found DBD apparently gets the socket setting not from mysql_config but from the mysql client libraries (libmysqlclient.a)

..and from what I can tell, there's no way to correct the socket in the mysql client libs without recompiling mysql. Not sure it would work anyway but I tried
./configure --without-server --prefix=/a_dir_i_can_write_to --with-unix-socket-path=/var/lib/mysql/mysql.sock

to generate new client libs but that fails, I think since I'm using the Site Manager's mysql installation & don't have root.....

unless there's some other way to get mysql client libs with the correct socket settings (*ahem* Westhost?), /tmp it is :)

thanks for the help