6:10 p.m.
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
6:16 p.m.
New subject: [Fedora-directory-users] Search by "uid" attribute returns duplicate results
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
6:26 p.m.
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. 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
7:31 p.m.
New subject: [Fedora-directory-users] Search by "uid" attribute returns duplicate results
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
7:45 a.m.
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
6:17 p.m.
New subject: [Fedora-directory-users] Search by "uid" attribute returns duplicate results
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.
6719
days inactive
6720
days old
389-users@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
David Boreham -
Kevin M. Myer -
Rich Megginson