Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/freeipa/ticket/2218 A bug in the creation of replication agreements caused the list of attributes to exclude to be dropped. That is being fixed separately but we need a way to refresh existing agreements.
What is the new command? Why was this utility created? When does an end-user need to run this? What does it fix? Is this something that should called internally only on an upgrade if so, should it not be documented or tested out of the context up upgrades? The upstream ticket is empty of information to.
From Rob: <snip> The problem is that memberOf is missing from list of attributes to EXCLUDE in nsDS5ReplicatedAttributeList. What my tool does is pull all replication agreements on a given server, look at that attribute for memberOf and if it isn't there, appends it and updates the agreement. This will need to be executed on every replica. The spec file will be updated to always run this tool when the server is updated, so updating the bits should be enough to apply the fix. </snip> When should the script be executed? How will they know that they need to do it? There are other questions unanswered from comment 1 still.
The script will be executed in %postinstall of the ipa-server rpm so any agreements will be updated automatically. Any existing agreements that are missing memberOf will be updated. Any existing agreements that already have memberOf will be ignored. What this tool does is query all agreements out of cn=mapping tree,cn=config and look at the value of nsDS5ReplicatedAttributeListTotal in each. If memberOf is not in the attribute we append it (it ends up in the EXCLUDE list). It would be possible for an end user to do the query and ldapmodify themselves, but it can be hairy and dangerous. There would be the real possibility of blowing up the replication agreement if done by hand. An end user MAY run this command. It will exit harmlessly if the agreements are updated and will update them if applicable. If run as root then it will autobind as Directory Manager, otherwise it will prompt for the Directory Manager password. It will not run against an IPA instance that is not updated (no agreements would exist anyway) so installing the new bits on a fresh system would not cause things to blow up.
Upstream ticket: https://fedorahosted.org/freeipa/ticket/2223
This will not be done as a tool but as an upgrade plugin. When ipa-ldap-updater runs it will execute code to check the agreements and update as necessary. A tool was added to ipa-2.1 (https://fedorahosted.org/freeipa/ticket/2218) I've unlinked 2218 from here because it applies only to the ipa-2-1 branch.
upgrade plugin has been pushed upstream in ticket 2223: master: https://fedorahosted.org/freeipa/changeset/ecf544ea0b5e5f8cc8b1339268bb85da90a03f03 ipa-2-2: https://fedorahosted.org/freeipa/changeset/2e9fed23328b8bdf567e6035e14547088d691cf6
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No documentation needed.
Verified. Version :: ipa-server-2.2.0-10.el6.x86_64 Automated Test Results :: ###### On MASTER server: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: upgrade_bz_772359_start: Need tool to update exclusive list in replication agreements :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [09:27:40] :: Machine in recipe is MASTER :: [09:27:40] :: capture LDAP mapping tree data before upgrade from MASTER (spoore-dvm1.testrelm.com) :: [ PASS ] :: Running 'ldapsearch -x -D "$ROOTDN" -w "$ROOTDNPWD" -b 'cn=mapping tree,cn=config' > /tmp/ldap_mapping_tree.out' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: upgrade_master: upgrade ipa master :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [09:28:03] :: Machine in recipe is MASTER ipa-server-2.1.3-9.el6.x86_64 389-ds-base-1.2.9.14-1.el6.x86_64 bind-9.7.3-8.P3.el6.x86_64 bind-dyndb-ldap-0.2.0-7.el6.x86_64 pki-common-9.0.3-20.el6.noarch sssd-1.5.1-66.el6.x86_64 :: [ PASS ] :: Running 'rpm -q ipa-server 389-ds-base bind bind-dyndb-ldap ...truncated leaving out excess... :: [ PASS ] :: Running 'yum clean all' ...truncated leaving out excess... :: [ PASS ] :: Running 'yum -y update 'ipa*'' ipa-server-2.2.0-10.el6.x86_64 389-ds-base-1.2.10.2-6.el6.x86_64 bind-9.8.2-0.7.rc1.el6.x86_64 bind-dyndb-ldap-1.1.0-0.5.b1.el6.x86_64 pki-common-9.0.3-24.el6.noarch sssd-1.8.0-22.el6.x86_64 :: [ PASS ] :: Running 'rpm -q ipa-server 389-ds-base bind bind-dyndb-ldap pki-common sssd' ###### On REPLICA server: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: upgrade_bz_772359_start: Need tool to update exclusive list in replication agreements :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [09:27:41] :: Machine in recipe is SLAVE result_server not set, assuming developer mode. Enter STATE:STATE:etc. when the following machines ['192.168.122.101'] are in one of these states: ['upgrade_bz_772359_start.6.1'] :: [ PASS ] :: Running 'rhts-sync-block -s 'upgrade_bz_772359_start.6.1' 192.168.122.101' :: [09:27:47] :: capture LDAP mapping tree data before upgrade from SLAVE (spoore-dvm2.testrelm.com) :: [ PASS ] :: Running 'ldapsearch -x -D "$ROOTDN" -w "$ROOTDNPWD" -b 'cn=mapping tree,cn=config' > /tmp/ldap_mapping_tree.out' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: upgrade_slave: upgade ipa slave :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [09:40:31] :: Machine in recipe is SLAVE ipa-server-2.1.3-9.el6.x86_64 389-ds-base-1.2.9.14-1.el6.x86_64 bind-9.7.3-8.P3.el6.x86_64 bind-dyndb-ldap-0.2.0-7.el6.x86_64 pki-common-9.0.3-20.el6.noarch sssd-1.5.1-66.el6.x86_64 :: [ PASS ] :: Running 'rpm -q ipa-server 389-ds-base bind bind-dyndb-ldap pki-common sssd' ...truncated leaving out excess... :: [ PASS ] :: Running 'yum clean all' ...truncated leaving out excess... :: [ PASS ] :: Running 'yum -y update 'ipa*'' ipa-server-2.2.0-10.el6.x86_64 389-ds-base-1.2.10.2-6.el6.x86_64 bind-9.8.2-0.7.rc1.el6.x86_64 bind-dyndb-ldap-1.1.0-0.5.b1.el6.x86_64 pki-common-9.0.3-24.el6.noarch sssd-1.8.0-22.el6.x86_64 :: [ PASS ] :: Running 'rpm -q ipa-server 389-ds-base bind bind-dyndb-ldap pki-common sssd' ###### On MASTER server: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: upgrade_bz_772359_finish: Need tool to update exclusive list in replication agreements :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [09:52:34] :: Machine in recipe is MASTER :: [09:52:34] :: capture LDAP mapping tree data before upgrade from MASTER (spoore-dvm1.testrelm.com) :: [ PASS ] :: Running 'ldapsearch -x -D "$ROOTDN" -w "$ROOTDNPWD" -b 'cn=mapping tree,cn=config' > /tmp/ldap_mapping_tree_after_upgrade.out' 40c40 < nsState:: BAAAAAAAAAAucpFPAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== --- > nsState:: BAAAAAAAAAD/dJFPAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAA== 42c42 < nsds5ReplicaChangeCount: 207 --- > nsds5ReplicaChangeCount: 85 59a60,72 > nsds50ruv: {replicageneration} 4f916928000000040000 > nsds50ruv: {replica 3 ldap://spoore-dvm2.testrelm.com:389} 4f91692f001c0003000 > 0 4f917388000300030000 > nsds50ruv: {replica 4 ldap://spoore-dvm1.testrelm.com:389} 4f9169a600000004000 > 0 4f9173ad000000040000 > nsruvReplicaLastModified: {replica 3 ldap://spoore-dvm2.testrelm.com:389} 0000 > 0000 > nsruvReplicaLastModified: {replica 4 ldap://spoore-dvm1.testrelm.com:389} 0000 > 0000 > nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof entryusn krbl > astsuccessfulauth krblastfailedauth krbloginfailedcount > nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts > uccessfulauth krblastfailedauth krbloginfailedcount 61,63c74,76 < nsds5replicaLastUpdateStart: 20120420142654Z < nsds5replicaLastUpdateEnd: 20120420142656Z < nsds5replicaChangesSentSinceStartup:: NDo3OC8wIA== --- > nsds5replicaLastUpdateStart: 20120420144440Z > nsds5replicaLastUpdateEnd: 20120420144440Z > nsds5replicaChangesSentSinceStartup:: NDo4LzAg 67,69c80,81 < nsds5replicaLastInitStart: 20120420134825Z < nsds5replicaLastInitEnd: 20120420134830Z < nsds5replicaLastInitStatus: 0 Total update succeeded --- > nsds5replicaLastInitStart: 0 > nsds5replicaLastInitEnd: 0 :: [ PASS ] :: Running 'diff /tmp/ldap_mapping_tree.out /tmp/ldap_mapping_tree_after_upgrade.out' :: [ PASS ] :: memberof found in Replication Agreement EXCLUDE list :: [ PASS ] :: BZ 772359 not found. result_server not set, assuming developer mode. Setting 192.168.122.101 to state upgrade_bz_772359_finish.11.1 :: [ PASS ] :: Running 'rhts-sync-set -s 'upgrade_bz_772359_finish.11.1' -m 192.168.122.101' result_server not set, assuming developer mode. Enter STATE:STATE:etc. when the following machines ['192.168.122.102'] are in one of these states: ['upgrade_bz_772359_finish.11.2'] :: [ PASS ] :: Running 'rhts-sync-block -s 'upgrade_bz_772359_finish.11.2' 192.168.122.102' ###### On REPLICA server: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: upgrade_bz_772359_finish: Need tool to update exclusive list in replication agreements :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [09:52:40] :: Machine in recipe is SLAVE result_server not set, assuming developer mode. Enter STATE:STATE:etc. when the following machines ['192.168.122.101'] are in one of these states: ['upgrade_bz_772359_finish.11.1'] :: [ PASS ] :: Running 'rhts-sync-block -s 'upgrade_bz_772359_finish.11.1' 192.168.122.101' :: [09:52:42] :: capture LDAP mapping tree data after upgrade from SLAVE (spoore-dvm2.testrelm.com) :: [ PASS ] :: Running 'ldapsearch -x -D "$ROOTDN" -w "$ROOTDNPWD" -b 'cn=mapping tree,cn=config' > /tmp/ldap_mapping_tree_after_upgrade.out' 40c40 < nsState:: AwAAAAAAAAAucpFPAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA== --- > nsState:: AwAAAAAAAACBdpFPAAAAAAAAAAAAAAAAAQAAAAAAAAADAAAAAAAAAA== 42c42 < nsds5ReplicaChangeCount: 207 --- > nsds5ReplicaChangeCount: 10 60,62c60,62 < nsds50ruv: {replica 4 ldap://spoore-dvm1.testrelm.com:389} < nsds50ruv: {replica 3 ldap://spoore-dvm2.testrelm.com:389} 4f91692f001c0003000 < 0 4f916943000200030000 --- > nsds50ruv: {replica 4 ldap://spoore-dvm1.testrelm.com:389} 4f9173ac00000004000 > 0 4f9174fd000000040000 > nsds50ruv: {replica 3 ldap://spoore-dvm2.testrelm.com:389} 67a68,71 > nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof entryusn krbl > astsuccessfulauth krblastfailedauth krbloginfailedcount > nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts > uccessfulauth krblastfailedauth krbloginfailedcount 69,71c73,75 < nsds5replicaLastUpdateStart: 20120420142654Z < nsds5replicaLastUpdateEnd: 20120420142654Z < nsds5replicaChangesSentSinceStartup:: Mzo4Ny8wIA== --- > nsds5replicaLastUpdateStart: 20120420145027Z > nsds5replicaLastUpdateEnd: 20120420145029Z > nsds5replicaChangesSentSinceStartup:: Mzo0MC8wIA== :: [ PASS ] :: Running 'diff /tmp/ldap_mapping_tree.out /tmp/ldap_mapping_tree_after_upgrade.out' :: [ PASS ] :: memberof found in Replication Agreement EXCLUDE list :: [ PASS ] :: BZ 772359 not found. result_server not set, assuming developer mode. Setting 192.168.122.102 to state upgrade_bz_772359_finish.11.2 :: [ PASS ] :: Running 'rhts-sync-set -s 'upgrade_bz_772359_finish.11.2' -m 192.168.122.102' Manual Test Results :: ###### On MASTER server post-upgrade: # ldapsearch -x -D "$ROOTDN" -w "$ROOTDNPWD" -b 'cn=meTospoore-dvm2.testrelm.com,cn=replica,cn=dc\3Dtestrelm\2Cdc\3Dcom,cn=mapping tree,cn=config' # extended LDIF # # LDAPv3 # base <cn=meTospoore-dvm2.testrelm.com,cn=replica,cn=dc\3Dtestrelm\2Cdc\3Dcom,cn=mapping tree,cn=config> with scope subtree # filter: (objectclass=*) # requesting: ALL # # meTospoore-dvm2.testrelm.com, replica, dc\3Dtestrelm\2Cdc\3Dcom, mapping tr ee, config dn: cn=meTospoore-dvm2.testrelm.com,cn=replica,cn=dc\3Dtestrelm\2Cdc\3Dcom,cn= mapping tree,cn=config cn: meTospoore-dvm2.testrelm.com objectClass: nsds5replicationagreement objectClass: top nsDS5ReplicaTransportInfo: LDAP description: me to spoore-dvm2.testrelm.com nsDS5ReplicaRoot: dc=testrelm,dc=com nsDS5ReplicaHost: spoore-dvm2.testrelm.com nsds5replicaTimeout: 120 nsDS5ReplicaPort: 389 nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicaUpdateSchedule: 0000-2359 0123456 nsds50ruv: {replicageneration} 4f916928000000040000 nsds50ruv: {replica 3 ldap://spoore-dvm2.testrelm.com:389} 4f91692f001c0003000 0 4f917388000300030000 nsds50ruv: {replica 4 ldap://spoore-dvm1.testrelm.com:389} 4f9169a600000004000 0 4f9173ad000000040000 nsruvReplicaLastModified: {replica 3 ldap://spoore-dvm2.testrelm.com:389} 0000 0000 nsruvReplicaLastModified: {replica 4 ldap://spoore-dvm1.testrelm.com:389} 0000 0000 nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof entryusn krbl astsuccessfulauth krblastfailedauth krbloginfailedcount nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts uccessfulauth krblastfailedauth krbloginfailedcount nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 20120420144440Z nsds5replicaLastUpdateEnd: 20120420144440Z nsds5replicaChangesSentSinceStartup:: NDo4LzAg nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd ate succeeded nsds5replicaUpdateInProgress: FALSE nsds5replicaLastInitStart: 0 nsds5replicaLastInitEnd: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ###### On REPLICA server: # ldapsearch -x -D "$ROOTDN" -w "$ROOTDNPWD" -b 'cn=meTospoore-dvm1.testrelm.com,cn=replica,cn=dc\3Dtestrelm\2Cdc\3Dcom,cn=mapping tree,cn=config' # extended LDIF # # LDAPv3 # base <cn=meTospoore-dvm1.testrelm.com,cn=replica,cn=dc\3Dtestrelm\2Cdc\3Dcom,cn=mapping tree,cn=config> with scope subtree # filter: (objectclass=*) # requesting: ALL # # meTospoore-dvm1.testrelm.com, replica, dc\3Dtestrelm\2Cdc\3Dcom, mapping tr ee, config dn: cn=meTospoore-dvm1.testrelm.com,cn=replica,cn=dc\3Dtestrelm\2Cdc\3Dcom,cn= mapping tree,cn=config cn: meTospoore-dvm1.testrelm.com objectClass: nsds5replicationagreement objectClass: top nsDS5ReplicaTransportInfo: LDAP description: me to spoore-dvm1.testrelm.com nsDS5ReplicaRoot: dc=testrelm,dc=com nsDS5ReplicaHost: spoore-dvm1.testrelm.com nsds5replicaTimeout: 120 nsDS5ReplicaPort: 389 nsDS5ReplicaBindMethod: SASL/GSSAPI nsds50ruv: {replicageneration} 4f916928000000040000 nsds50ruv: {replica 4 ldap://spoore-dvm1.testrelm.com:389} 4f9173ac00000004000 0 4f9174fd000000040000 nsds50ruv: {replica 3 ldap://spoore-dvm2.testrelm.com:389} nsruvReplicaLastModified: {replica 4 ldap://spoore-dvm1.testrelm.com:389} 0000 0000 nsruvReplicaLastModified: {replica 3 ldap://spoore-dvm2.testrelm.com:389} 0000 0000 nsDS5ReplicaUpdateSchedule: 0000-2359 0123456 nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof entryusn krbl astsuccessfulauth krblastfailedauth krbloginfailedcount nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts uccessfulauth krblastfailedauth krbloginfailedcount nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 20120420151042Z nsds5replicaLastUpdateEnd: 20120420151044Z nsds5replicaChangesSentSinceStartup:: Mzo3Ni8wIA== nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd ate succeeded nsds5replicaUpdateInProgress: FALSE nsds5replicaLastInitStart: 0 nsds5replicaLastInitEnd: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0819.html