Hi Rich, apologies for the delay in replying, I've been out of the office for a couple of days. On 12/04/2013 08:31 AM, Rich Megginson wrote: > 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. I was able to work around the problem by changing the filter on those roles that weren't working -- so it's not a major issue for us now. However, I'm still trying to work out why it happened. > 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"? Yes. The objectclass chain for one example user looks like this: nscpEntryWSI: objectClass;adcsn-5296e4e8000064a40000;vucsn-5296e4e8000064a40000: top nscpEntryWSI: objectClass;vucsn-5296e4e8000064a40000: inetOrgPerson nscpEntryWSI: objectClass;vucsn-5296e4e8000064a40000: posixAccount nscpEntryWSI: objectClass;vucsn-5296e66c000164a40000: ntUser nscpEntryWSI: objectClass;vucsn-5296e48b000064a40000;deleted: organizationalPerson nscpEntryWSI: objectClass;vucsn-5296e48b000064a40000;deleted: person I note the 'deleted' flag on the 'person' and 'organizationalPerson' values. I checked the other users in the same boat, and for *some*, it's that the intermediate parents are marked as 'deleted', and on others they simply don't exist; for example: nscpEntryWSI: objectClass;adcsn-5276ebaf000064a40001;vucsn-5276ebaf000064a40001: top nscpEntryWSI: objectClass;vucsn-5276ebaf000064a40001: inetOrgPerson nscpEntryWSI: objectClass;vucsn-5276ebaf000064a40001: posixAccount nscpEntryWSI: objectClass;vucsn-5276ec06000064a40000: inetUser nscpEntryWSI: objectClass;vucsn-5276ee0d000064a40000: ntUser > 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. Ok, from the above I get that the replica ID is 64a4, which is 25764 -- I know which replica of ours this is (we have an internally-meaningful numbering scheme) > > 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. Unfortunately when I got back to the originating server, the changelog holding the create event had expired so I wasn't able to see the original entry. Instead, I added a user (via ldapadd on the command-line) and traced the replication via that method, but only specifying the "leaf" classes; the intermediate classes *were* properly filled in and were replicated correctly. At this point, I'm not sure what I can do to re-replicate the issue. I'll keep an eye out for it again, and I'm very happy to assist in further triage if you have any ideas, but from where I sit right now it appears the trail has gone cold. Thanks for the hints in tracking it further. -- C. -- Colin Panisset Tech Lead - Infrastructure, REA Group Ph: +61 (0)3 8456 4636 Mb: +61 (0) 457 788 259 -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
