[Date Prev][Date Next]
Re: Looking for proven version
Kirk A. Turner-Rustin wrote:
On Wed, 22 Oct 2003, Jehan PROCACCIA wrote:
Don't know if it's related, but I see you talking about RH and kernels versions.
I am wondering why in openldap 2.1.22 RedHat rpm packages the start script
(/etc/init.d/ldap) includes a "export LD_ASSUME_KERNEL=2.4.1" ?
On one of my server I had to remove that env var to enable a proper start of
Any clues on that ? thanks .
PS: I use RedHat 9 .
The line you mention does not appear in our /etc/rc.d/init.d/ldap.
oops ! strange ! I did also recompiled 2.1.22 from rawhide to my RH 9
system 2.4.20-8 kernel. However I do have a "export
LD_ASSUME_KERNEL=2.4.1" in init script . Perhaps it comes from the
original openldap rpms (2.0.27 in RH9 in thinks) and my rpm -U didn't
replaced files ?
We are running OpenLDAP 2.1.22 built from the RedHat RawHide SRPM on
three RedHat 9 boxes with all kernel and other updates from RH.
I am following this thread with some trepidation because I am preparing to
migrate these directories from back-ldbm to back-bdb (we just ordered a
second hard disk for each of our two production LDAP servers for storing
the transaction logs).
I run with bdb backends, it works fine exept some databases "crash"
sometimes , but it comes back to normal after a db_revcover
(/usr/sbin/slapd_db_recover -v) .
If a "feature" in the RH9 kernel is going to ditz my indexes after we
switch to bdb, I may hold off. Our server manager would balk at my using
a non-RH kernel on these boxes because it will complicate our patching
routines. Nathan: Were you running the most recent RH9 kernel
(2.4.20-20.9) before you switched to the one you compiled yourself?
Selon Nathan Ehresman <email@example.com>:
Thanks for replying. Yeah, I'm positive it is something with RedHat 9, but
I'll be boogered if I can't figure out exactly what's corrupting those
indexes. When I move the exact same stuff over to a RedHat 7.2 machine (I
don't have any Solaris boxes to play with), it works like a charm. If
indeed the kernel change seems to take care of it (I should know in a week
or so), I'll let the list know if for nothing else than archive
documentation for other people who might search for the same behavior.
Jehan Procaccia, Ingenieur Systemes & Reseaux
Institut National des Telecommunications, Tel : +33 (0) 160764436
MCI,Moyens Communs Informatiques, Mail: Jehan.Procaccia@int-evry.fr
9 rue Charles Fourier 91011 Evry France, Fax : +33 (0) 160764321