[Date Prev][Date Next]
RE: Search results not complete at base level after slapd start
8,814 entries, using (I believe) db-4.0.14 (supplied with distro). The cn attribute is indexed.
Further testing shows that the problem doesn't seem to be with the database structure, more like the attributes used. The two entries in question are defined as "extensibleObject", with a structural
object class of "applicationProcess", because this was the only one I could find that would support the combination of attributes I needed.
It doesn't seem to matter what I put in the database. I've deleted and reloaded multiple times. I've removed everything except the top-level entries, and even rearranged those, but the symptom stays
the same. The only thing that DID work was changing the uidmin and uidmax entries to use "account" as the SOC, with posixAccount and shadowAccount, but that requires additional attributes I didn't
want to have.
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Dieter
> Sent: Monday, November 17, 2003 12:26 PM
> To: openldap-software@OpenLDAP.org
> Subject: Re: Search results not complete at base level after
> slapd start
> "Hall, Ken (IDS ECCS)" <email@example.com> writes:
> > Running Openldap 2.1.4, the base of my directory tree contains seven
> > entries in the following order: Two admin accounts, "ou=People",
> > "ou=Groups", "ou=mounts", "cn=uidmin", and "cn=uidmax".
> > The last two entries store the "next available UID number" range for
> > my maintenance scripts.
> > This worked fine with Openldap 2.0, but I've noticed since upgrading
> > to 2.1 that when slapd first starts, searches will not return all of
> > the DN's at the base of the tree. The ones missing are always happen
> > to be the last two or three added, which happen to be the "mounts",
> > "uidmin" and "uidmax" entries. This is the case for both generic
> > searches, and specific ones like "cn=uidmin".
> > If I repeat the search a few times, it eventually finds the entries,
> > but this causes problems with my maintenance scripts. The
> behavior is
> > present both for ldapsearch, and a Windows-based LDAP browser, so I
> > know it's not just the search process failing.
> > Since the problem is so intermittent, I'm not sure how to go about
> > writing a bug report for it. I'm going to try to duplicate it in a
> > controlled environment.
> How many entries?
> What database?
> cachsize of database?
> are the relevant attributes indexed?
> If database is bdb, do a db_stat
> Dieter Kluenter | Systemberatung
> Tel:040.64861967 | Fax: 040.64891521
> mailto: dkluenter(at)dkluenter.de