[Opendnssec-user] Problem with custom sqlite install path

[Ville Mattila]

Hi,

On Wed, 14 Apr 2010, Ondřej Surý wrote:

> On Tue, Apr 13, 2010 at 10:29, Ville Mattila <vmattila at csc.fi> wrote:

> I am not an expert, but I have some experience from Debian, where we
> fight rpath quite usually.

> Usually rpath is evil for distributions, since it causes all the
> strange things like the one you have described, etc., etc.

Indeed, Debian seems to discourage rpath usage in packages:
http://wiki.debian.org/RpathIssue

>> My question to OpenDNSSEC developers is that do you think "libtool
>> --mode=link" calls should include also "-rpath $SQLITE3" argument
>> where $SQLITE3 is the path specified by the user with "configure
>> --with-sqlite3"?  Without this I'm unable to see how runtime linker
>> ever could locate the correct SQLite libraries that might reside
>> elsewhere from $libdir.
>
> Usually it's much better to not have rpath in binaries and let the
> dynamic linker do it's work.
>
> But that's not your case - Try to find utility named chrpath and run
> chrpath -r ${SQLITE3_PATH} ${binary} .
> (http://linux.die.net/man/1/chrpath)

Thanks for the hint.  I'll try if mangling the binaries chrpath would
let me ditch some of the awful sed etc. hacks I've currently in the RPM
package for building a custom new enough sqlite and statically linking
it into the opendnssec binaries.

>>  (And obviously adding $SQLITE3 to ld.so.conf
>> is not an acceptable option because all other programs runtime linked
>> to SQLite would end up using the custom libraries as well.)
>
> And is that a problem? sqlite3 libraries have same SONAME, so they
> should be compatible with newer sqlite3 library.

Yes it is a problem.

If I expose the custom sqlite3 libraries by adding their install path
(/opt/opendnssec-sqlite/lib) to ld.so.conf it would be practically same as
replacing the system default sqlite3 installation directly (in /usr/lib*):
All programs (including e.g. /bin/rpm) would thereafter be linked to my
custom /opt/opendnssec-sqlite/lib/libsqlite3.so.0 and nobody would be
using the official /usr/lib*/libsqlite3.so.0.  I'm afraid of the
newer sqlite3 libraries being incompatible/buggy wrt RHEL5 tools and
thus would prefer only opendnssec using the custom sqlite3 libraries.

But perhaps it is not a problem for most users to (effectively) replace
RHEL 5 official sqlite in their OpenDNSSEC servers.

>> BTW, a workaround for this could be hide the actual opendnssec binaries
>> under e.g. /usr/libexec/opendnssec/ and create (a) generic wrapper
>> shell script(s) into /usr/bin/ and /usr/sbin/ that export(s)
>> LD_LIBRARY_PATH=$SQLITE3 before exec'ing the actual binary.
>
> Do you have some start scripts for opendnssec? It should be enough to
> add LD_LIBRARY_PATH to them.

I'm using the ods-control delivered with opendnssec-1.0.0 as init script
so yes, LD_LIBRARY_PATH could be exported from there and that should be
enough provided ods-enforcerd and the signer engine would never get
started directly but always via the init script.

> You can also use aliases in your shell,
> like:
>
> alias ods-enforcerd="LD_LIBRARY_PATH=/usr/local/lib /tmp/xxxxx/ods-enforcerd"

Sure.  Another trick could be creating a script e.g. 
/usr/libexec/opendnssec/bin/ods-wrap:
-----
#!/usr/bin/perl -w
use File::Basename;

$ENV{LD_LIBRARY_PATH} = "/opt/opendnssec-sqlite/lib";

exec("/usr/libexec/opendnssec/bin/" . basename($0), @ARGV);
-----

The real ods-* binaries would thus be installed into
/usr/libexec/opendnssec/bin/ and symlinks with the same names
would be placed instead in /usr/bin/.  For example:
   /usr/bin/ods-ksmutil => /usr/libexec/opendnssec/bin/ods-wrap
   /usr/libexec/opendnssec/bin/ods-wrap => ods-ksmutil

So far all the methods for installing OpenDNSSEC on RHEL5 without
replacing the default sqlite seem rather tedious (at least from package
maintaining perspective).  Statically linking a custom sqlite version
can be done and seems to work ok in our test setup.  I'll see if the
chrpath mangling and/or shell aliases + init script modification for
exporting $LD_LIBRARY_PATH would result in cleaner (i.e. easier to
maintain and thus better) package.

Ville