Kevin M. Myer wrote:
Quoting Richard Megginson <rmeggins@xxxxxxxxxx>: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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
