Kevin M. Myer wrote: > Quoting Richard Megginson <rmeggins at 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20051128/d35c9d3c/attachment.bin
