Hello,
I migrated a Netscape Directory Server 4.16 installation to Fedora Directory Server over the weekend. It went very smoothly, but I now have a puzzling problem. I have two servers setup in multimaster replication mode. On the one server, for one subtree only, if I search via the 'uid' attribute, each search returns two identical entries. On the other server, if I search via the 'uid' attribute, I get one entry. If I search on anything but the 'uid' attribute (say, for instance 'mail'), I get one result from both servers.
The server that returns duplicate results for the 'uid' searches was running in a test mode prior to my migration. However, I wiped the database/subtree that had our organization accounts located in it prior to migrating. My initial suspicion is that I have a messed up index somewhere but I don't see how I would ever have been able to import duplicate sets of entries anyway, since we are using 'uid' as our RDN value. Further, if I export the data for that subtree, there are only one set of entries for each account.
Thoughts on what might be occuring?
Kevin
Kevin M. Myer wrote:
Hello,
I migrated a Netscape Directory Server 4.16 installation to Fedora Directory Server over the weekend. It went very smoothly, but I now have a puzzling problem. I have two servers setup in multimaster replication mode. On the one server, for one subtree only, if I search via the 'uid' attribute, each search returns two identical entries. On the other server, if I search via the 'uid' attribute, I get one entry. If I search on anything but the 'uid' attribute (say, for instance 'mail'), I get one result from both servers.
The server that returns duplicate results for the 'uid' searches was running in a test mode prior to my migration. However, I wiped the database/subtree that had our organization accounts located in it prior to migrating. My initial suspicion is that I have a messed up index somewhere but I don't see how I would ever have been able to import duplicate sets of entries anyway, since we are using 'uid' as our RDN value.
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.
Further, if I export the data for that subtree, there are only one set of entries for each account.
Right, because there is only 1 real entry, it's just that there are two different uid values in the index pointing to your 1 real entry.
Thoughts on what might be occuring?
Kevin
Quoting Richard Megginson rmeggins@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. 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?
Kevin
Kevin M. Myer wrote:
Quoting Richard Megginson rmeggins@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
I used the good master set of data to reinitialize the server that had duplicate uid's and that seemed to do the trick. Thanks to all for your responses and suggestions.
Kevin
Thoughts on what might be occuring?
Not really. But I wonder if it's returning two entries or the same entry twice ? Can you try modifying an entry and see if 'both' copies are modified in the search results ?
The next things I'd recommend would be running the search with logging verbosity turned way up and posting the results here. That should show us why the search returned two entries. Another thing to try is to use the dbscan utility to examine the indices. The fact that only one copy of the entries is output from db2ldif would suggest that there's really only one copy in the database, but somehow the index has become broken such that there are two copies of the same ID in the ID List. But that's not supposed to be able to happen...
Sometimes migration can do strange things when it uses the underlying database files from the old server, but that wouldn't have happened in a 4.x to 7.x migration.
389-users@lists.fedoraproject.org
-
David Boreham -
Kevin M. Myer -
Rich Megginson