[Date Prev][Date Next]
Re: Reasons for Statically linking to Bekely DB?
I can't speak for other people, but the reason I like to have a separate,
statically linked Berkeley DB behind my LDAP servers is so that I don't have to
Scenario: a PFY is assigned to make the veeblefester service work faster at
processing froznits. He determines that the version of Berkeley DB in use on
the system is not up to date, and he needs the latest version to support faster
veeblefester daemons. He cheerfully upgrades the db (after extensive testing
on his development box, of course :) ) and a previously unknown bug hoses
OpenLDAP completely, preventing end-user logins and forcing a reboot in single-
user mode in order to repair the damage. Company loses 1.5 million dollars net
income due to downtime. All PFYs receive repeated beatings about the head and
neck (which increases morale among the end-users but discourages creativity
among programming staff).
A service which controls system availability should only run with known good
tested libraries, and these should not be upgraded unless a security problem is
known to exist or an additional function is required.
On 4 Apr 2004 at 22:16, Edward Rudd wrote:
Subject: Reasons for Statically linking to Bekely DB?
From: Edward Rudd <email@example.com>
To: OpenLDAP <openldap-software@OpenLDAP.org>
Organization: Omegaware Systems Ltd.
Date sent: Sun, 04 Apr 2004 22:16:40 -0500
> I am compiling my own RPMS for my server, and have noted that several of
> the existing RPMS of Openldap, mostly 2.0.x series, are compiled in such
> a way that the Berkeley DB is statically linked to the server binary as
> opposed to dynamically linked to the system DB library. Is there any
> reason to do this? And will I run into problems if my system ships with
> DB 4.1.25, and I compile OpenLDAP with DB version 4.2.52?
> Edward Rudd <firstname.lastname@example.org>
> Website http://outoforder.cc/