389-commits August 2020

389-commits@lists.fedoraproject.org

1 participants
15 discussions

[389-ds-base] branch 389-ds-base-1.4.3 updated: Issue 51228 - Fix lock/unlock wording and lib389 use of methods
by pagure＠pagure.io 27 Aug '20

27 Aug '20

1 0

[389-ds-base] branch 389-ds-base-1.4.2 updated: Issue 51228 - Fix lock/unlock wording and lib389 use of methods
by pagure＠pagure.io 27 Aug '20

27 Aug '20

1 0

[389-ds-base] branch 389-ds-base-1.4.3 updated: Issue 51229 - Server Settings page gets into an unresponsive state
by pagure＠pagure.io 20 Aug '20

20 Aug '20

1 0

[389-ds-base] branch 389-ds-base-1.4.2 updated: Issue 51229 - Server Settings page gets into an unresponsive state
by pagure＠pagure.io 20 Aug '20

20 Aug '20

1 0

[389-ds-base] branch 389-ds-base-1.4.2 updated: Issue 51165 - Set the operation start time for extended ops
by pagure＠pagure.io 17 Aug '20

17 Aug '20

This is an automated email from the git hooks/post-receive script. mreynolds pushed a commit to branch 389-ds-base-1.4.2 in repository 389-ds-base. The following commit(s) were added to refs/heads/389-ds-base-1.4.2 by this push: new 1b05d81 Issue 51165 - Set the operation start time for extended ops 1b05d81 is described below commit 1b05d81a213dabed9601400797da4df51d5856ed Author: Mark Reynolds <mreynolds(a)redhat.com> AuthorDate: Mon Aug 17 09:20:07 2020 -0400 Issue 51165 - Set the operation start time for extended ops Bug Description: Extended ops, likewhat is used in replication, were not setting the operation start time. This caused invalid values in the new access log keywords (wtime & optime) Fix Description: Set the start start at the start of the extended op. Fixes: https://pagure.io/389-ds-base/issue/51165 Reviewed by: mreynolds (one line commit rule) --- ldap/servers/slapd/extendop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ldap/servers/slapd/extendop.c b/ldap/servers/slapd/extendop.c index f9f19d3..6aba026 100644 --- a/ldap/servers/slapd/extendop.c +++ b/ldap/servers/slapd/extendop.c @@ -221,6 +221,9 @@ do_extended(Slapi_PBlock *pb) slapi_pblock_get(pb, SLAPI_OPERATION, &pb_op); slapi_pblock_get(pb, SLAPI_CONNECTION, &pb_conn); + /* Set the time we actually started the operation */ + slapi_operation_set_time_started(pb_op); + if (pb_conn == NULL || pb_op == NULL) { send_ldap_result(pb, LDAP_OPERATIONS_ERROR, NULL, "param error", 0, NULL); slapi_log_err(SLAPI_LOG_ERR, "do_extended", -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[389-ds-base] branch 389-ds-base-1.4.3 updated: Issue 51165 - Set the operation start time for extended ops
by pagure＠pagure.io 17 Aug '20

17 Aug '20

This is an automated email from the git hooks/post-receive script. mreynolds pushed a commit to branch 389-ds-base-1.4.3 in repository 389-ds-base. The following commit(s) were added to refs/heads/389-ds-base-1.4.3 by this push: new 25eaefe Issue 51165 - Set the operation start time for extended ops 25eaefe is described below commit 25eaefe06cee20081c4bd89b2d3c762213a35652 Author: Mark Reynolds <mreynolds(a)redhat.com> AuthorDate: Mon Aug 17 09:20:07 2020 -0400 Issue 51165 - Set the operation start time for extended ops Bug Description: Extended ops, likewhat is used in replication, were not setting the operation start time. This caused invalid values in the new access log keywords (wtime & optime) Fix Description: Set the start start at the start of the extended op. Fixes: https://pagure.io/389-ds-base/issue/51165 Reviewed by: mreynolds (one line commit rule) --- ldap/servers/slapd/extendop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ldap/servers/slapd/extendop.c b/ldap/servers/slapd/extendop.c index 4ebbeca..2c2f9c7 100644 --- a/ldap/servers/slapd/extendop.c +++ b/ldap/servers/slapd/extendop.c @@ -279,6 +279,9 @@ do_extended(Slapi_PBlock *pb) slapi_pblock_get(pb, SLAPI_OPERATION, &pb_op); slapi_pblock_get(pb, SLAPI_CONNECTION, &pb_conn); + /* Set the time we actually started the operation */ + slapi_operation_set_time_started(pb_op); + if (pb_conn == NULL || pb_op == NULL) { send_ldap_result(pb, LDAP_OPERATIONS_ERROR, NULL, "param error", 0, NULL); slapi_log_err(SLAPI_LOG_ERR, "do_extended", -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[389-ds-base] branch master updated: Issue 51165 - Set the operation start time for extended ops
by pagure＠pagure.io 17 Aug '20

17 Aug '20

This is an automated email from the git hooks/post-receive script. mreynolds pushed a commit to branch master in repository 389-ds-base. The following commit(s) were added to refs/heads/master by this push: new dda3ab0 Issue 51165 - Set the operation start time for extended ops dda3ab0 is described below commit dda3ab0da56c42aa529bca35d7a05604f2076f75 Author: Mark Reynolds <mreynolds(a)redhat.com> AuthorDate: Mon Aug 17 09:20:07 2020 -0400 Issue 51165 - Set the operation start time for extended ops Bug Description: Extended ops, likewhat is used in replication, were not setting the operation start time. This caused invalid values in the new access log keywords (wtime & optime) Fix Description: Set the start start at the start of the extended op. Fixes: https://pagure.io/389-ds-base/issue/51165 Reviewed by: mreynolds (one line commit rule) --- ldap/servers/slapd/extendop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ldap/servers/slapd/extendop.c b/ldap/servers/slapd/extendop.c index 4ebbeca..2c2f9c7 100644 --- a/ldap/servers/slapd/extendop.c +++ b/ldap/servers/slapd/extendop.c @@ -279,6 +279,9 @@ do_extended(Slapi_PBlock *pb) slapi_pblock_get(pb, SLAPI_OPERATION, &pb_op); slapi_pblock_get(pb, SLAPI_CONNECTION, &pb_conn); + /* Set the time we actually started the operation */ + slapi_operation_set_time_started(pb_op); + if (pb_conn == NULL || pb_op == NULL) { send_ldap_result(pb, LDAP_OPERATIONS_ERROR, NULL, "param error", 0, NULL); slapi_log_err(SLAPI_LOG_ERR, "do_extended", -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[389-ds-base] branch master updated: Issue 50933 - Fix OID change between 10rfc2307 and 10rfc2307compat
by pagure＠pagure.io 12 Aug '20

12 Aug '20

This is an automated email from the git hooks/post-receive script. mreynolds pushed a commit to branch master in repository 389-ds-base. The following commit(s) were added to refs/heads/master by this push: new 5afcbb0 Issue 50933 - Fix OID change between 10rfc2307 and 10rfc2307compat 5afcbb0 is described below commit 5afcbb0d53e06aee85373df32c87bf830d41c251 Author: Mark Reynolds <mreynolds(a)redhat.com> AuthorDate: Wed Aug 12 12:46:42 2020 -0400 Issue 50933 - Fix OID change between 10rfc2307 and 10rfc2307compat Bug Description: 10rfc2307compat changed the OID for nisMap objectclass to match the standard OID, but this breaks replication with older versions of DS. Fix Description: Continue to use the old(invalid?) oid for nisMap so that replication does not break in a mixed version environment. Fixes: https://pagure.io/389-ds-base/issue/50933 Reviewed by: firstyear & tbordaz(Thanks!!) --- ldap/schema/10rfc2307compat.ldif | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ldap/schema/10rfc2307compat.ldif b/ldap/schema/10rfc2307compat.ldif index 78c588d..8ba72e1 100644 --- a/ldap/schema/10rfc2307compat.ldif +++ b/ldap/schema/10rfc2307compat.ldif @@ -253,7 +253,7 @@ objectClasses: ( MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) objectClasses: ( - 1.3.6.1.1.1.2.9 NAME 'nisMap' SUP top STRUCTURAL + 1.3.6.1.1.1.2.13 NAME 'nisMap' SUP top STRUCTURAL DESC 'A generic abstraction of a NIS map' MUST nisMapName MAY description -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[389-ds-base] branch 389-ds-base-1.4.3 updated: Issue 51228 - Clean up dsidm user status command
by pagure＠pagure.io 11 Aug '20

11 Aug '20

1 0

[389-ds-base] branch 389-ds-base-1.4.2 updated: Issue 51228 - Clean up dsidm user status command
by pagure＠pagure.io 11 Aug '20

11 Aug '20

1 0

[389-ds-base] branch 389-ds-base-1.3.10 updated: Issue 51233 - ds-replcheck crashes in offline mode
by pagure＠pagure.io 10 Aug '20

10 Aug '20

This is an automated email from the git hooks/post-receive script. mreynolds pushed a commit to branch 389-ds-base-1.3.10 in repository 389-ds-base. The following commit(s) were added to refs/heads/389-ds-base-1.3.10 by this push: new 22d6739 Issue 51233 - ds-replcheck crashes in offline mode 22d6739 is described below commit 22d67399b82773c8e49f408caf8c2eea81c3b089 Author: Mark Reynolds <mreynolds(a)redhat.com> AuthorDate: Thu Aug 6 14:50:19 2020 -0400 Issue 51233 - ds-replcheck crashes in offline mode Bug Description: When processing all the DN's found in the Master LDIF it is possible that the LDIF is not in the expected order and ldifsearch fails (crashing the tool). Fix Description: If ldifsearch does not find an entry, start from the beginning of the LDIF and try again. relates: https://pagure.io/389-ds-base/issue/51233 Reviewed by: spichugi(Thanks!) --- ldap/admin/src/scripts/ds-replcheck | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ldap/admin/src/scripts/ds-replcheck b/ldap/admin/src/scripts/ds-replcheck index aea32fd..eef68e1 100755 --- a/ldap/admin/src/scripts/ds-replcheck +++ b/ldap/admin/src/scripts/ds-replcheck @@ -637,6 +637,10 @@ def do_offline_report(opts, output_file=None): missing = False for dn in master_dns: mresult = ldif_search(MLDIF, dn) + if mresult['entry'] is None and mresult['conflict'] is None and not mresult['tombstone']: + # Try from the beginning + MLDIF.seek(0) + mresult = ldif_search(MLDIF, dn) rresult = ldif_search(RLDIF, dn) if dn in replica_dns: -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[389-ds-base] branch 389-ds-base-1.4.2 updated: Issue 51233 - ds-replcheck crashes in offline mode
by pagure＠pagure.io 10 Aug '20

10 Aug '20

This is an automated email from the git hooks/post-receive script. mreynolds pushed a commit to branch 389-ds-base-1.4.2 in repository 389-ds-base. The following commit(s) were added to refs/heads/389-ds-base-1.4.2 by this push: new 59a8111 Issue 51233 - ds-replcheck crashes in offline mode 59a8111 is described below commit 59a811178ac203ddb5699a3dc3dfb138f317308f Author: Mark Reynolds <mreynolds(a)redhat.com> AuthorDate: Thu Aug 6 14:50:19 2020 -0400 Issue 51233 - ds-replcheck crashes in offline mode Bug Description: When processing all the DN's found in the Master LDIF it is possible that the LDIF is not in the expected order and ldifsearch fails (crashing the tool). Fix Description: If ldifsearch does not find an entry, start from the beginning of the LDIF and try again. relates: https://pagure.io/389-ds-base/issue/51233 Reviewed by: spichugi(Thanks!) --- ldap/admin/src/scripts/ds-replcheck | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ldap/admin/src/scripts/ds-replcheck b/ldap/admin/src/scripts/ds-replcheck index 5bb7dfc..1c133f4 100755 --- a/ldap/admin/src/scripts/ds-replcheck +++ b/ldap/admin/src/scripts/ds-replcheck @@ -725,6 +725,10 @@ def do_offline_report(opts, output_file=None): missing = False for dn in master_dns: mresult = ldif_search(MLDIF, dn) + if mresult['entry'] is None and mresult['conflict'] is None and not mresult['tombstone']: + # Try from the beginning + MLDIF.seek(0) + mresult = ldif_search(MLDIF, dn) rresult = ldif_search(RLDIF, dn) if dn in replica_dns: -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[389-ds-base] branch 389-ds-base-1.4.3 updated: Issue 51233 - ds-replcheck crashes in offline mode
by pagure＠pagure.io 10 Aug '20

10 Aug '20

This is an automated email from the git hooks/post-receive script. mreynolds pushed a commit to branch 389-ds-base-1.4.3 in repository 389-ds-base. The following commit(s) were added to refs/heads/389-ds-base-1.4.3 by this push: new 5e4d162 Issue 51233 - ds-replcheck crashes in offline mode 5e4d162 is described below commit 5e4d1625e6904721efa5595641184e5ee7daa501 Author: Mark Reynolds <mreynolds(a)redhat.com> AuthorDate: Thu Aug 6 14:50:19 2020 -0400 Issue 51233 - ds-replcheck crashes in offline mode Bug Description: When processing all the DN's found in the Master LDIF it is possible that the LDIF is not in the expected order and ldifsearch fails (crashing the tool). Fix Description: If ldifsearch does not find an entry, start from the beginning of the LDIF and try again. relates: https://pagure.io/389-ds-base/issue/51233 Reviewed by: spichugi(Thanks!) --- ldap/admin/src/scripts/ds-replcheck | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ldap/admin/src/scripts/ds-replcheck b/ldap/admin/src/scripts/ds-replcheck index 5bb7dfc..1c133f4 100755 --- a/ldap/admin/src/scripts/ds-replcheck +++ b/ldap/admin/src/scripts/ds-replcheck @@ -725,6 +725,10 @@ def do_offline_report(opts, output_file=None): missing = False for dn in master_dns: mresult = ldif_search(MLDIF, dn) + if mresult['entry'] is None and mresult['conflict'] is None and not mresult['tombstone']: + # Try from the beginning + MLDIF.seek(0) + mresult = ldif_search(MLDIF, dn) rresult = ldif_search(RLDIF, dn) if dn in replica_dns: -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[389-ds-base] branch 389-ds-base-1.4.3 updated: Issue 50260 - Fix test according to #51222 fix
by pagure＠pagure.io 06 Aug '20

06 Aug '20

This is an automated email from the git hooks/post-receive script. spichugi pushed a commit to branch 389-ds-base-1.4.3 in repository 389-ds-base. The following commit(s) were added to refs/heads/389-ds-base-1.4.3 by this push: new 444fe6f Issue 50260 - Fix test according to #51222 fix 444fe6f is described below commit 444fe6fbf16a14da161c69be5b7a9f2ca6422462 Author: Simon Pichugin <spichugi(a)redhat.com> AuthorDate: Wed Aug 5 14:35:06 2020 +0200 Issue 50260 - Fix test according to #51222 fix Description: Managed Entry plugin behaviour was fixed and returned codes were cleaned up. Now we allow to continue modrdn and delete managing entry operations execution even when managed entry doesn't exists. Also allow 'cn=directory manager' to delete managed entry on direct update. Make the updates fail using another way. https://pagure.io/389-ds-base/issue/50260 https://pagure.io/389-ds-base/issue/51222 Reviewed by: mreynolds (Thanks!) --- dirsrvtests/tests/suites/betxns/betxn_test.py | 38 +++++++++++++++++++-------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/dirsrvtests/tests/suites/betxns/betxn_test.py b/dirsrvtests/tests/suites/betxns/betxn_test.py index aab2392..b5ca010 100644 --- a/dirsrvtests/tests/suites/betxns/betxn_test.py +++ b/dirsrvtests/tests/suites/betxns/betxn_test.py @@ -18,12 +18,14 @@ from lib389.plugins import (SevenBitCheckPlugin, AttributeUniquenessPlugin, from lib389.idm.user import UserAccounts, TEST_USER_PROPERTIES from lib389.idm.organizationalunit import OrganizationalUnits from lib389.idm.group import Groups, Group +from lib389.idm.domain import Domain from lib389._constants import DEFAULT_SUFFIX pytestmark = pytest.mark.tier1 logging.getLogger(__name__).setLevel(logging.DEBUG) log = logging.getLogger(__name__) +USER_PASSWORD = 'password' def test_betxt_7bit(topology_st): @@ -253,6 +255,15 @@ def test_ri_and_mep_cache_corruption(topology_st): 5. Success """ + # Add ACI so we can test that non-DM user can't delete managed entry + domain = Domain(topology_st.standalone, DEFAULT_SUFFIX) + ACI_TARGET = f"(target = \"ldap:///{DEFAULT_SUFFIX}\")" + ACI_TARGETATTR = "(targetattr = *)" + ACI_ALLOW = "(version 3.0; acl \"Admin Access\"; allow (all) " + ACI_SUBJECT = "(userdn = \"ldap:///anyone\");)" + ACI_BODY = ACI_TARGET + ACI_TARGETATTR + ACI_ALLOW + ACI_SUBJECT + domain.add('aci', ACI_BODY) + # Start plugins topology_st.standalone.config.set('nsslapd-dynamic-plugins', 'on') mep_plugin = ManagedEntriesPlugin(topology_st.standalone) @@ -270,15 +281,15 @@ def test_ri_and_mep_cache_corruption(topology_st): mep_template1 = mep_templates.create(properties={ 'cn': 'MEP template', 'mepRDNAttr': 'cn', - 'mepStaticAttr': 'objectclass: posixGroup|objectclass: extensibleObject'.split('|'), + 'mepStaticAttr': 'objectclass: groupOfNames|objectclass: extensibleObject'.split('|'), 'mepMappedAttr': 'cn: $cn|uid: $cn|gidNumber: $uidNumber'.split('|') }) mep_configs = MEPConfigs(topology_st.standalone) mep_configs.create(properties={'cn': 'config', - 'originScope': ou_people.dn, - 'originFilter': 'objectclass=posixAccount', - 'managedBase': ou_groups.dn, - 'managedTemplate': mep_template1.dn}) + 'originScope': ou_people.dn, + 'originFilter': 'objectclass=posixAccount', + 'managedBase': ou_groups.dn, + 'managedTemplate': mep_template1.dn}) # Add an entry that meets the MEP scope users = UserAccounts(topology_st.standalone, DEFAULT_SUFFIX, @@ -291,6 +302,8 @@ def test_ri_and_mep_cache_corruption(topology_st): 'gidNumber': '20011', 'homeDirectory': '/home/test-user1' }) + user.reset_password(USER_PASSWORD) + user_bound_conn = user.bind(USER_PASSWORD) # Add group groups = Groups(topology_st.standalone, DEFAULT_SUFFIX) @@ -304,22 +317,25 @@ def test_ri_and_mep_cache_corruption(topology_st): # Test MEP be txn pre op failure does not corrupt entry cache # Should get the same exception for both rename attempts + # Try to remove the entry while bound as Admin (non-DM) + managed_groups_user_conn = Groups(user_bound_conn, ou_groups.dn, rdn=None) + managed_entry_user_conn = managed_groups_user_conn.get(user.rdn) with pytest.raises(ldap.UNWILLING_TO_PERFORM): - mep_group.rename("cn=modrdn group") - + managed_entry_user_conn.rename("cn=modrdn group") with pytest.raises(ldap.UNWILLING_TO_PERFORM): - mep_group.rename("cn=modrdn group") + managed_entry_user_conn.rename("cn=modrdn group") # Mess with MEP so it fails mep_plugin.disable() - mep_group.delete() + users_mep_group = UserAccounts(topology_st.standalone, mep_group.dn, rdn=None) + users_mep_group.create_test_user(1001) mep_plugin.enable() # Add another group to verify entry cache is not corrupted test_group = groups.create(properties={'cn': 'test_group'}) - # Delete user, should fail in MEP be txn post op, and user should still be a member - with pytest.raises(ldap.NO_SUCH_OBJECT): + # Try to delete user - it fails because managed entry can't be deleted + with pytest.raises(ldap.NOT_ALLOWED_ON_NONLEAF): user.delete() # Verify membership is intact -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

[389-ds-base] branch 389-ds-base-1.4.2 updated: Issue 50260 - Fix test according to #51222 fix
by pagure＠pagure.io 06 Aug '20

06 Aug '20

This is an automated email from the git hooks/post-receive script. spichugi pushed a commit to branch 389-ds-base-1.4.2 in repository 389-ds-base. The following commit(s) were added to refs/heads/389-ds-base-1.4.2 by this push: new 6e2e790 Issue 50260 - Fix test according to #51222 fix 6e2e790 is described below commit 6e2e7900bef2d78da17a97a9d3c3cc3a71dcb5ed Author: Simon Pichugin <spichugi(a)redhat.com> AuthorDate: Wed Aug 5 14:35:06 2020 +0200 Issue 50260 - Fix test according to #51222 fix Description: Managed Entry plugin behaviour was fixed and returned codes were cleaned up. Now we allow to continue modrdn and delete managing entry operations execution even when managed entry doesn't exists. Also allow 'cn=directory manager' to delete managed entry on direct update. Make the updates fail using another way. https://pagure.io/389-ds-base/issue/50260 https://pagure.io/389-ds-base/issue/51222 Reviewed by: mreynolds (Thanks!) --- dirsrvtests/tests/suites/betxns/betxn_test.py | 38 +++++++++++++++++++-------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/dirsrvtests/tests/suites/betxns/betxn_test.py b/dirsrvtests/tests/suites/betxns/betxn_test.py index ee160df..5bb3196 100644 --- a/dirsrvtests/tests/suites/betxns/betxn_test.py +++ b/dirsrvtests/tests/suites/betxns/betxn_test.py @@ -18,12 +18,14 @@ from lib389.plugins import (SevenBitCheckPlugin, AttributeUniquenessPlugin, from lib389.idm.user import UserAccounts, TEST_USER_PROPERTIES from lib389.idm.organizationalunit import OrganizationalUnits from lib389.idm.group import Groups, Group +from lib389.idm.domain import Domain from lib389._constants import DEFAULT_SUFFIX pytestmark = pytest.mark.tier1 logging.getLogger(__name__).setLevel(logging.DEBUG) log = logging.getLogger(__name__) +USER_PASSWORD = 'password' def test_betxt_7bit(topology_st): @@ -249,6 +251,15 @@ def test_ri_and_mep_cache_corruption(topology_st): 5. Success """ + # Add ACI so we can test that non-DM user can't delete managed entry + domain = Domain(topology_st.standalone, DEFAULT_SUFFIX) + ACI_TARGET = f"(target = \"ldap:///{DEFAULT_SUFFIX}\")" + ACI_TARGETATTR = "(targetattr = *)" + ACI_ALLOW = "(version 3.0; acl \"Admin Access\"; allow (all) " + ACI_SUBJECT = "(userdn = \"ldap:///anyone\");)" + ACI_BODY = ACI_TARGET + ACI_TARGETATTR + ACI_ALLOW + ACI_SUBJECT + domain.add('aci', ACI_BODY) + # Start plugins topology_st.standalone.config.set('nsslapd-dynamic-plugins', 'on') mep_plugin = ManagedEntriesPlugin(topology_st.standalone) @@ -266,15 +277,15 @@ def test_ri_and_mep_cache_corruption(topology_st): mep_template1 = mep_templates.create(properties={ 'cn': 'MEP template', 'mepRDNAttr': 'cn', - 'mepStaticAttr': 'objectclass: posixGroup|objectclass: extensibleObject'.split('|'), + 'mepStaticAttr': 'objectclass: groupOfNames|objectclass: extensibleObject'.split('|'), 'mepMappedAttr': 'cn: $cn|uid: $cn|gidNumber: $uidNumber'.split('|') }) mep_configs = MEPConfigs(topology_st.standalone) mep_configs.create(properties={'cn': 'config', - 'originScope': ou_people.dn, - 'originFilter': 'objectclass=posixAccount', - 'managedBase': ou_groups.dn, - 'managedTemplate': mep_template1.dn}) + 'originScope': ou_people.dn, + 'originFilter': 'objectclass=posixAccount', + 'managedBase': ou_groups.dn, + 'managedTemplate': mep_template1.dn}) # Add an entry that meets the MEP scope users = UserAccounts(topology_st.standalone, DEFAULT_SUFFIX, @@ -287,6 +298,8 @@ def test_ri_and_mep_cache_corruption(topology_st): 'gidNumber': '20011', 'homeDirectory': '/home/test-user1' }) + user.reset_password(USER_PASSWORD) + user_bound_conn = user.bind(USER_PASSWORD) # Add group groups = Groups(topology_st.standalone, DEFAULT_SUFFIX) @@ -300,22 +313,25 @@ def test_ri_and_mep_cache_corruption(topology_st): # Test MEP be txn pre op failure does not corrupt entry cache # Should get the same exception for both rename attempts + # Try to remove the entry while bound as Admin (non-DM) + managed_groups_user_conn = Groups(user_bound_conn, ou_groups.dn, rdn=None) + managed_entry_user_conn = managed_groups_user_conn.get(user.rdn) with pytest.raises(ldap.UNWILLING_TO_PERFORM): - mep_group.rename("cn=modrdn group") - + managed_entry_user_conn.rename("cn=modrdn group") with pytest.raises(ldap.UNWILLING_TO_PERFORM): - mep_group.rename("cn=modrdn group") + managed_entry_user_conn.rename("cn=modrdn group") # Mess with MEP so it fails mep_plugin.disable() - mep_group.delete() + users_mep_group = UserAccounts(topology_st.standalone, mep_group.dn, rdn=None) + users_mep_group.create_test_user(1001) mep_plugin.enable() # Add another group to verify entry cache is not corrupted test_group = groups.create(properties={'cn': 'test_group'}) - # Delete user, should fail in MEP be txn post op, and user should still be a member - with pytest.raises(ldap.NO_SUCH_OBJECT): + # Try to delete user - it fails because managed entry can't be deleted + with pytest.raises(ldap.NOT_ALLOWED_ON_NONLEAF): user.delete() # Verify membership is intact -- To stop receiving notification emails like this one, please contact the administrator of this repository.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-commits August 2020