Re: Corrupt index files

[John Dalbec <jpdalbec@cc.ysu.edu>]

Darren Gamble wrote:
> 
> Good day,
> 
> We're running 2.0.21 on a number of Redhat 7.2 machines (installed via Red
> Hat RPM).
> 
> I've noticed on a couple of occasions that the index files appear to go
> corrupt, yielding bad results on searching.  The problem goes away if the
> index file in question is removed and recreated with slapindex.  It's not
> restricted to any one machine and seems to just happen sporadically.
> 
> I recall reading about something similar on the mailing list awhile back,

That was probably me.  I installed Berkeley DB 3.3.11 (now in Red Hat
7.3) and rebuilt the source RPM for openldap-2.0.21 after removing the
"--with-ldap-api=gdbm" configure directive.  It then uses Berkeley DB
automatically.  To upgrade you'll have to dump and restore your LDAP
database since the file formats are incompatible.  You can minimize the
impact by running a read-only LDAP server on a copy of your database
(preferably on another machine).  If you do this on the same machine
make sure you use the --noscripts option when upgrading or the RPM may
restart your LDAP server and then you'll be dead in the water until you
finish restoring the database.  You'll have to run ldconfig by hand
after upgrading the RPM with --noscripts.
John Dalbec

> but the "Search" function for the openldap-software mailing list on
> OpenLDAP's site currently always returns 0 results regardless of what I type
> in.   I found a few non-mailing list messages via Googling- some hinted that
> this was fixed in a new version of Berkely DB, some that hinted that this
> was fixed in 2.0.22, but nothing conclusive.  So, please bear with me if
> this has already been discussed here, as I have tried very hard to find
> previous messages on the topic.
> 
> I've defined the database type as "ldbm", but all of our files are ".gdbm"-
> I'm assuming that the database backend type is ldbm.  We have version 3.2.9
> of Berkely DB installed (the version that comes with Red Hat 7.2) which is
> what I'm assuming is getting used for the backend.
> 
> Has this been repaired in a more recent version of the backend or the
> server?  Upgrading would be a considerable amount of testing and work on all
> of the servers, so I'd like to avoid it unless a problem has been identified
> with the versions we have now (not trying to be lazy, I just don't want to
> possibly introduce a new problem that blows up a bunch of servers since we
> use LDAP for authentication and the system is working mostly-fine now).
> There is an entry in the changelog for 2.0.22 that hints that this may have
> been fixed in that version...
> 
> Is there anything else that I could supply to help with this?
> 
> Thanks in advance for everyone's time,
> 
> ============================
> Darren Gamble
> Planner, Regional Services
> Shaw Cablesystems GP
> 630 - 3rd Avenue SW
> Calgary, Alberta, Canada
> T2P 4L4
> (403) 781-4948