[Fedora-directory-users] Search by "uid" attribute returns duplicate results

[Kevin M. Myer]

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
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

[Rich Megginson]

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
>

[David Boreham]

>  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.

[Kevin M. Myer]

Quoting Richard Megginson <rmeggins(a)redhat.com&gt;:


>  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
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

[Rich Megginson]

Kevin M. Myer wrote:

>  Quoting Richard Megginson <rmeggins(a)redhat.com&gt;:
>
>
> > 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
>

[Kevin M. Myer]

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

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org