On 12/02/2013 06:42 PM, Colin Panisset wrote:
I have a 4-way multi-master replication configuration; the servers are
slightly different versions, as below:
A - 1.2.9.9-1.el5 (CentOS 5)
B - 1.2.9.9-1.el5 (CentOS 5)
C - 1.2.10.2-20.el6_3 (CentOS 6)
D - 1.2.11.15-22.el6_4 (CentOS 6)
D was recently brought into the configuration to replace A (ultimately).
I initialized D as a consumer directly from A, and I've confirmed that
replication proceeds throughout the mesh without apparent incident --
there are no errors in /var/log/dirsrv/slapd*/errors relating to
replication.
The problem is that *some* objects under ou=people,dc=foo,dc=bar on D do
not show some objectclasses, notably "person" and
"organizationalPerson". These values don't show up in the output of
ldapsearch, via the console, or when used by an internal search process,
such as populating an nsFilteredRole.
Is this the blocker problem, that filtered roles are not working? Just
trying to gauge the severity.
What is the full objectclass chain for these entries? That is, are
these "inetOrgPerson" entries that are missing the intermediate parent
object classes "person" and "organizationalPerson"?
What you can do is work backwards from these entries that are missing
these objectclasses.
1) do an ldapsearch like this to get the replication state information:
ldapsearch -xLLL -D "cn=directory manager" -W -b dc=foo,dc=bar
uid=myuser nscpEntryWSI
among the data will be the first CSN for the entry. The CSN looks like this
TTTTTTTTSSSSRRRRUUUU
Where TTTTTTTT is the 8 hex bytes of the timestamp, SSSS is a sequence
number, and RRRR is the replica ID of the server on which the entry
originated. The RRRR is in hex.
Next, go to the server on which the entry originated. Do this:
dbscan -f /var/lib/dirsrv/slapd-*/cldb/*.db4 -k $theoriginalCSN
The server is supposed to "fill in" the missing parent object classes
during the original add request, but perhaps not during a replicated add.
These objects *do* have those objectclasses visible on all the other
servers (A, B, and C). Searches against those other servers return
expected results.
If I explicitly add the objectclass to the object via server D, the
objectclasses are now visible. Added objectclasses do not create
duplicates on the other servers in the replication mesh.
Has anyone seen anything like this before? The objects which exhibit
this behaviour don't seem to have any commonality with each other, and
are interspersed (by createtimestamp) with other almost identical
objects which do *not* exhibit the behaviour.
If the answer is "known bug fixed in version BLAH", then I'm perfectly
happy.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
