Norman Gaywood wrote, on 28. feb 2007 23:41:
> On Wed, Feb 28, 2007 at 04:44:20AM +0100, Tony Earnshaw wrote:
>> FWIW the Red Hat RHAS4 db-4.2.52 installed as-is causes OpenLDAP to
>> puke; I built and install my own rpms, patched to the hilt, and install
> I what way does this break on RHAS4?
For my installs OL 2.3 complains about the environment; I'm not sure
which - could be TXN - it's been such a long time ...
> I'm currently testing a self compiled 2.3.34 openldap with the default
> RH db4-4.2.52-7.1.
Indeed, if one asks up2date to --get db4, this is the version you get.
I should first try Buchan Milne's srpm if I were installing on
RHAS/RHEL4 (which I in fact do).
> The changelog for db4-4.2.52-7.1 includes changes that seem to have been
> talked about in this thread:
> * Tue Jun 08 2004 Jeff Johnson <jbj(a)jbj.org> 4.2.52-4
> - remove dangling symlinks (#123721 et al).
> - remove db_cxx.so and db_tcl.so symlinks, versioned equivs exist.
> - apply 2 patches from sleepycat.
A couple of or 4 symlinks (not these) were wrong in Red Hat's rpm and I
fixed those in my rpm. It didn't cause any harm in practice, but
ldconfig complained each time it was run.
As for the patches, there could have been 2 in 2004, then there were
later 4 and I think the latter have since been condensed into a single
patch, which I apply. I also apply Quanah's bdb-transactions.patch,
which is most likely redundant now. Buchan applies 4 Sleepycat patches
to his OL 2.3 rpms.
It's not possible to go to Sleepycat's site and find out any longer,
since Oracle's taken the thing over and messed everything up. I can't
get at 4.2.52 any more.
> - resurrect db4-java using sun jvm-1.4.2.
> - cripple autoconf sufficiently to build db4-java with gcj, without jvm.
> - check javac first, gcj34 next, then gcj-ssa, finally gcj.
> - add ed build dependency (#125180).
>> them with my own Cyrus SASL 2.2.22 rpms on any RHAS4 system I install.
>> Buchan also builds his own discrete-sonamed db-4.2.52 stuff for his
>> OpenLDAP 2.3 on systems where db-4.2.52 might give problems.
As for the Cyrus SASL stuff, I need it built with Howard's ldapdb and
the standard build doesn't do that, one has to tell it to.
Email: tonni at hetnet dot nl
Buchan Milne [mailto:firstname.lastname@example.org]
> > Well, I just ran db_archive and caused widespread chaos
> because most (all?)
> > of the replicas stopped responding to queries. (I have yet
> to perform a
> > post-mortem)
> You ran db_archive for the first time, on *all* replicas at
> the same time????
Yes. We administer 80+ servers that are more or less identically configured,
and typically perform small admin tasks in "for" loop, which is what I did
in this case.
> > I know that there's a bug in bdb 4.2 that causes logs to be
> held open even
> > though they're no longer required. Upgrading bdb is not on
> the cards right
> > now so I need to work around that problem by stopping and starting
> > openldap.
> This may or may not be the cause of your problems.
> Additionally, this is
> affected by your database configuration and checkpointing settings.
> > So the question I have just at the moment is, when I run
> db_archive, should
> > openldap be running or not running?
> It should be safe, depending on your configuration, to run
> However, due to the tasks it does (just deleting all the
> unused log files
> would have a similar effect), it can be quite IO intensive,
> and you may incur
> IO starvation when doing it, impacting performance of any
> other application
> using files on the same block devices (e.g. slapd).
As an additional piece of background, we are currently running all the
replication out of an intermediate server (it's a transistional setup). As
far as I can tell, it all hit the fan when the db_archive ran on that
intermediate server. Obviously I should have left that one out of the list
but I didn't think of it at the time.
These are all the non-comment entries in DB_CONFIG:
set_cachesize 0 268435456 1
Database definition entries in slapd.conf:
Replication entries on most servers:
And replication entries on the intermediate host:
syncprov-checkpoint 10 5
Linux Systems Administrator
Opus International Consultants Ltd
Tel +64 4 471 7002, Fax +64 4 473 3017
Level 9 Majestic Centre, 100 Willis Street, PO Box 12 343
Wellington, New Zealand
Has openLDAP implemented the Get Effective Rights control extension? I
tried using "2.16.840.1.113722.214.171.124.33" (getEffectivePrivilegesRequest);
however, got a "not implemented" result.
I searched around google and the list archives and saw some references to
it, but never a reference to whether it was implemented or not.
I'm trying to move an application that was running against novell's
eDirectory to openLDAP and it makes heavy use of this control. That OID may
be novell specific, but i didn't see anything in ldap.h with that name
Any insight would be appreciated