Kevin M. Myer wrote:
Quoting Richard Megginson <rmeggins(a)redhat.com>:
> Sounds like a messed up index i.e. when you wiped the
> database/subtree, it didn't wipe the uid.db4 index file. However,
> if you initialized the database again by importing an LDIF file (e.g.
> by ldif2db, not ldapmodify -a), it should have wiped out the old
> index as well.
I used the Admin Console to do the creation/wiping and importing. Not
sure which mechanism that invokes.
Looks like it didn't clean up correctly. Also, import from the console
may be using the equivalent of ldapmodify -a, which just adds the new
entries without wiping out the old. If you use the "initialize
database" option, it should do a full destructive import.
So far it hasn't created major problems, except with RADIUS
authentication, since freeradius apparently wants a unique entry when
a LDAP BIND occurs. I'm envisioning the need to completely wipe
things for this subtree on one server. If I disable replication both
ways for this subtree, delete the subtree on the errant server, then
enable replication and initialize from the good set of data, that
should take care of things, right? Or is there an even simpler way to
recreate the index?
You could try db2index, but reimport is the fastest and safest way.
Kevin