You know I loved CPAN until I started writing the LUMP installer but now I’m not so keen!

It looks like our cunning plan of allowing people to install the required modules to run LUMP from CPAN using point-n-dribble web front end might have come unstuck for a couple of reasons.  The major one is having Perl modules that use XS to rely on C code/libraries/etc that might not actually be installed on the target machine.  For example we need to use the ZOOM Perl module for Z39.50 access.  This in turn makes use of the Yaz toolkit, which you either need to build from source or get an RPM for… and there aren’t any RPMs in the standard CentOS repos (you can pull CentOS RPMs from Index Data’s web site but not get them via yum).   Similar requirements for Expat, although at least that has yum’ed packages in CentOS.  I not noticed either of these because on my Debian Lenny based workstation there were already handy packages in place and the Perl modules that I’d been “needing” were pure Perl.   I only stumbled across the issue when Jason created a “sandbox” virtual machine running CentOS and I tried to run the installer on there.  Even if I could guess the package manager on use on the machine (yum, apt, etc) I’d need to ask the Admin for the system root password and then have to deal with the out of repo code such as Yaz.  At this point the law of diminishing returns kicked in and we decided we’d wasted enough time trying to make a user friendly installer and it wasn’t going to be easy to get round these problems.

Still, all is not lost: at least the installer code can spot which modules are missing so that you can install them by hand.  In fact I’ve left the code into install private CPAN modules – we might as well do as much as possible for the prospective Admin even if we do then need to tell them to break out the C compiler and build some support software.  And of course the installer can still do everything else once the required Perl modules are in place – create the DB, import test data, and retrieve and configure the various scripts required.

I also accidentally stumbled across another problem today: DBD::MySQL doesn’t allow column filters in the column_info() DBI method.  I was using that to check if the LUMP database schema on the target machine, if present, was out of date compared to the schema embedded in the installer.  This is a bit of a pain but relatively simple to code round.  The DBI manual page implies that if a DBD module can’t do filtering you might have to handle it yourself: DBD::MySQL just barfs with an error message so I’ve had to embed the call in eval() checks just to be on the safe side.

I’ve also just noticed that I’ve hard coded the Kerberos TGT realm!  Oops – we’ll need to change that, especially as we’re just moving ActiveDirectory trees here at Loughborough anyway!  We’ll probably also need to add in an override ability for folk with no AD or other Kerberized authentication infrastructure – that shouldn’t take too much work as its just a little tweak inside the LUMP.pm password validation method.  Hopefully in a week or so we’ll have little demo system on our sandbox VM that we can then let people play with – a bit like the demo system that we already run for LORLS v5 (our “groundhog day” install, that gets blown away every morning in the wee hours and replaced with a fresh copy… in fact I used the LORLSv5 to LUMP importer to convert that database into our new format for this new sandbox machine as another useful test).