Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: This may affect 389 Directory Server in general but, I specifically saw this behavior in my IPA test env. After a good bit of troubleshooting, and getting dev involved, Rich found that the RUV data was excluded from replication (at least in some cases): From Rich: However, I do see it in the changelog on f18-2: dbid: 519b96d3000000030000 replgen: 1369151185 Tue May 21 10:46:25 2013 csn: 519b96d3000000030000 uniqueid: c4a8008c-c15d11e2-81caa921-5c226755 dn: fqdn=f18-2.testrelm.com,cn=computers,cn=accounts,dc=testrelm,dc=com operation: modify krbLastSuccessfulAuth: 20130521154625Z modifiersname: cn=Directory Manager modifytimestamp: 20130521154625Z entryusn: 1068 All of these attributes are excluded from replication, which means it will be in the local RUV but not in any other RUVs. Version-Release number of selected component (if applicable): 389-ds-base-1.3.0.6-1.fc18.x86_64 How reproducible: very Steps to Reproduce: 1. Setup a few IPA servers 2. use ldapsearch (like below) to compare the RUV data for each server on each server for RUV in $MASTER $REPLICA1 $REPLICA2 $REPLICA3 $REPLICA4; do for SERVER in $MASTER $REPLICA1 $REPLICA2 $REPLICA3 $REPLICA4; do RUVCHK=$(ldapsearch -o ldif-wrap=no -h $SERVER \ -xLLL -D "$ROOTDN" -w $ROOTDNPWD -b $BASEDN \ '(&(objectclass=nstombstone)(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff))' \ nsds50ruv|grep $RUV); echo "$(echo $SERVER|cut -f1 -d.): $RUVCHK" done echo done Actual results: You see some differences in the last field (MaxCSN): f18-1: nsds50ruv: {replica 4 ldap://f18-1.testrelm.com:389} 519a3a2b000000040000 519a8ec5000000040000 f18-2: nsds50ruv: {replica 4 ldap://f18-1.testrelm.com:389} 519a3a2b000000040000 519a8ec5000000040000 f18-3: nsds50ruv: {replica 4 ldap://f18-1.testrelm.com:389} 519a3a2b000000040000 519a8ec5000000040000 f18-4: nsds50ruv: {replica 4 ldap://f18-1.testrelm.com:389} 519a3a2b000000040000 519a8ec5000000040000 f18-5: nsds50ruv: {replica 4 ldap://f18-1.testrelm.com:389} 519a3a2b000000040000 519a8ec5000000040000 f18-1: nsds50ruv: {replica 3 ldap://f18-2.testrelm.com:389} 519a39ea000000030000 519a7c32000400030000 f18-2: nsds50ruv: {replica 3 ldap://f18-2.testrelm.com:389} 519a39ea000000030000 519a81b2000200030000 f18-3: nsds50ruv: {replica 3 ldap://f18-2.testrelm.com:389} 519a39ea000000030000 519a7c32000400030000 f18-4: nsds50ruv: {replica 3 ldap://f18-2.testrelm.com:389} 519a39ea000000030000 519a7c32000400030000 f18-5: nsds50ruv: {replica 3 ldap://f18-2.testrelm.com:389} 519a39ea000000030000 519a7c32000400030000 f18-1: nsds50ruv: {replica 5 ldap://f18-3.testrelm.com:389} 519a3cfc000000050000 519a447b000500050000 f18-2: nsds50ruv: {replica 5 ldap://f18-3.testrelm.com:389} 519a3cfc000000050000 519a447b000500050000 f18-3: nsds50ruv: {replica 5 ldap://f18-3.testrelm.com:389} 519a3cfc000000050000 519a8138000100050000 f18-4: nsds50ruv: {replica 5 ldap://f18-3.testrelm.com:389} 519a3cfc000000050000 519a8138000100050000 f18-5: nsds50ruv: {replica 5 ldap://f18-3.testrelm.com:389} 519a3cfc000000050000 519a8138000100050000 f18-1: nsds50ruv: {replica 6 ldap://f18-4.testrelm.com:389} 519a40fc000000060000 519a4477000600060000 f18-2: nsds50ruv: {replica 6 ldap://f18-4.testrelm.com:389} 519a40fc000000060000 519a4477000600060000 f18-3: nsds50ruv: {replica 6 ldap://f18-4.testrelm.com:389} 519a40fc000000060000 519a4477000600060000 f18-4: nsds50ruv: {replica 6 ldap://f18-4.testrelm.com:389} 519a40fc000000060000 519a813b000300060000 f18-5: nsds50ruv: {replica 6 ldap://f18-4.testrelm.com:389} 519a40fc000000060000 519a813b000300060000 f18-1: nsds50ruv: {replica 7 ldap://f18-5.testrelm.com:389} 519a43a1000000070000 519a4483000000070000 f18-2: nsds50ruv: {replica 7 ldap://f18-5.testrelm.com:389} 519a43a1000000070000 519a4483000000070000 f18-3: nsds50ruv: {replica 7 ldap://f18-5.testrelm.com:389} 519a43a1000000070000 519a4483000000070000 f18-4: nsds50ruv: {replica 7 ldap://f18-5.testrelm.com:389} 519a43a1000000070000 519a4483000000070000 f18-5: nsds50ruv: {replica 7 ldap://f18-5.testrelm.com:389} 519a43a1000000070000 519a813e000000070000 Expected results: Entries match or some other definitive way to confirm that the directory servers are in sync. Additional info:
Upstream ticket: https://fedorahosted.org/389/ticket/47368
Summary of new monitoring process: To manually check if a consumer is up to date, you compare the agreements max csn, located in the local ruv tombstone entry, to the consumers RUV element for the suppliers rid. Here is the format of the new attribute/value: nsds5AgmtMaxCSN: <repl area>:<agmt name>:<consumer host>:<consumer port>:<consumer rid>:<maxcsn> nsds5AgmtMaxCSN: dc=example,dc=com;to replica;localhost.localdomain;389;111;5270095c0000014d0000 Example: Check if Replica B is caught up with Replica A Replica A (rid 222): ldapsearch -h localhost -D "cn=directory manager" -W -b "dc=example,dc=com" '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' -xLLL nsds50ruv nsds5AgmtMaxCSN dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds50ruv: {replica 222 ldap://localhost.localdomain:389} 527283720000006f0000 52729c8b0000006f0000 nsds5AgmtMaxCSN: dc=example,dc=com;to replica B;localhost.localdomain;22222;65535;52729c8b0000006f0000 nsds5AgmtMaxCSN: dc=example,dc=com;to replica C;localhost.localdomain;22222;444;52729c999900006f0000 Look at the nsds5AgmtMaxCSN attributes, and locate the agreement for replica B, and get its max csn value (52729c8b0000006f0000). Then compare this max csn to the max csn on Replica B(nsds50ruv) for replica 222(Replica A): Replica B (rid 65535): ldapsearch -h localhost -D "cn=directory manager" -W -b "dc=example,dc=com" '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' -p 22222 -xLLL nsds50ruv dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds50ruv: {replica 222 ldap://localhost.localdomain:389} 527283720000006f0000 52729c8b0000006f0000 nsds50ruv: {replica 444 ldap://localhost.localdomain:389} 527283af0000006f0000 527299990000006f0000 We are in sync in this example. So now each agreement can be monitored, and this is also the only way to correctly tell if fractional replication agreements are in sync. The repl-monitor.pl script has also been improved to work with this new process. There is a new plain text report that can also be parsed for desired information.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.