We would need to test this scenario, but it could very likely be a bug in the server. To be sure the conditions you have here are: ou=start,dc=… ou=destination,dc=… In ou=start you have 800+ entries. Then you are doing a modrdn of ou=start to ou=start,ou=destination,dc=…, and the error condition occurs? Is this correct? > On 21 Feb 2019, at 02:49, Olivier JUDITH <gnulux(a)gmail.com&gt; wrote: > > Hi, > > I have activated Referential Integrity plugin on my instance in order to move several OU to a new parent subtree. Also to update automatically uniqueMember attribute defined in group member . > It works fine with few user entries under some OU but fails when the OU contains more than 400 entries or somtime more than 800. > The error from the 389-console is : > ou=UNITA, OU=Accounts,dc=mydomain,dc=com: netscape.ldap.LDAPException: error result (1); Operations error. > In error file > [20/Feb/2019:17:37:59.123749991 +0100] - ERR - ldbm_back_modrdn - SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set SLAPI_RESULT_CODE > > After this error the OU : UNITA, OU=Accounts,dc=mydomain,dc=com is not visible from 389-console . I have to restart the instance in order to recover the OU. > > Did i miss something in my configuration or do i have to set a specific parameter to support big entries ? > > My installation : 389DS 1.3.6 . > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...

On 21 Feb 2019, at 13:12, William Brown <wbrown(a)suse.de&gt; wrote: > On 21 Feb 2019, at 08:57, Olivier JUDITH <gnulux(a)gmail.com&gt; wrote: > > Hi, > > I'm moving many ou to one level up > ou=SITE1,ou=BU,ou=Account,dc=... > ou=SITE2,ou=BU,ou=Account,dc=... > to > ou=SITE1,ou=Account,dc=...... > ou=SITE2,ou=Account,dc=... > > Don't want OU=BU anymore. > > ou=SITE1,ou=Account,dc=... has less than 100 entries it works fine > ou=SITE2,ou=Account,dc=... has more than 400 entries , works randomly. Today i succeeded to move it (after instance restart) . So i tried another OU with more than 1000 entries and i got the > same error. I am going to attempt to reproduce this, and I will report the results to you tomorrow :)

> > Regards > > Le mer. 20 févr. 2019 à 23:44, William Brown <wbrown(a)suse.de&gt; a écrit : > We would need to test this scenario, but it could very likely be a bug in the server. > > To be sure the conditions you have here are: > > ou=start,dc=… > ou=destination,dc=… > > In ou=start you have 800+ entries. > > Then you are doing a modrdn of ou=start to ou=start,ou=destination,dc=…, and the error condition occurs? > > Is this correct? > >> On 21 Feb 2019, at 02:49, Olivier JUDITH <gnulux(a)gmail.com&gt; wrote: >> >> Hi, >> >> I have activated Referential Integrity plugin on my instance in order to move several OU to a new parent subtree. Also to update automatically uniqueMember attribute defined in group member . >> It works fine with few user entries under some OU but fails when the OU contains more than 400 entries or somtime more than 800. >> The error from the 389-console is : >> ou=UNITA, OU=Accounts,dc=mydomain,dc=com: netscape.ldap.LDAPException: error result (1); Operations error. >> In error file >> [20/Feb/2019:17:37:59.123749991 +0100] - ERR - ldbm_back_modrdn - SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set SLAPI_RESULT_CODE >> >> After this error the OU : UNITA, OU=Accounts,dc=mydomain,dc=com is not visible from 389-console . I have to restart the instance in order to recover the OU. >> >> Did i miss something in my configuration or do i have to set a specific parameter to support big entries ? >> >> My installation : 389DS 1.3.6 . >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... > > — > Sincerely, > > William Brown > Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs

Sorry, this formatted, poorly. Find attached, > On 21 Feb 2019, at 14:17, William Brown <wbrown(a)suse.de&gt; wrote: > > > >> On 21 Feb 2019, at 13:12, William Brown <wbrown(a)suse.de&gt; wrote: >> >> >> >>> On 21 Feb 2019, at 08:57, Olivier JUDITH <gnulux(a)gmail.com&gt; wrote: >>> >>> Hi, >>> >>> I'm moving many ou to one level up >>> ou=SITE1,ou=BU,ou=Account,dc=... >>> ou=SITE2,ou=BU,ou=Account,dc=... >>> to >>> ou=SITE1,ou=Account,dc=...... >>> ou=SITE2,ou=Account,dc=... >>> >>> Don't want OU=BU anymore. >>> >>> ou=SITE1,ou=Account,dc=... has less than 100 entries it works fine >>> ou=SITE2,ou=Account,dc=... has more than 400 entries , works randomly. Today i succeeded to move it (after instance restart) . So i tried another OU with more than 1000 entries and i got the >>> same error. >> >> I am going to attempt to reproduce this, and I will report the results to you tomorrow :) > > Hey there, > > I can’t reproduce this. A likely explanation could be that it affects versions less than 1.4.x (which is what I was testing against). > Here is the test case. Can you check that it matches your expectations? It may look a bit foreign as it’s based on our python lib389 suite: > > # --- BEGIN COPYRIGHT BLOCK --- > # Copyright (C) 2019 William Brown <william(a)blackhats.net.au&gt; > # All rights reserved. > # > # License: GPL (version 3 or any later version). > # See LICENSE for details. > # --- END COPYRIGHT BLOCK --- > # > > > from lib389._constants import DEFAULT_SUFFIX > from lib389.topologies import topology_st > > from lib389.idm.group import Groups > from lib389.idm.user import nsUserAccounts > from lib389.idm.organizationalunit import OrganizationalUnit as OrganisationalUnit > > from lib389.plugins import AutoMembershipPlugin, ReferentialIntegrityPlugin, AutoMembershipDefinitions > > > def test_rename_large_subtree(topology_st): > """ > A report stated that the following configuration would lead > to an operation failure: > > ou=int,ou=account,dc=... > ou=s1,ou=int,ou=account,dc=... > ou=s2,ou=int,ou=account,dc=... > > rename ou=s1 to re-parent to ou=account, leaving: > > ou=int,ou=account,dc=... > ou=s1,ou=account,dc=... > ou=s2,ou=account,dc=... > > The ou=s1 if it has < 100 entries below, is able to be reparented. > > If ou=s1 has > 400 entries, it fails. > > Other conditions was the presence of referential integrity - so one would > assume that all users under s1 are a member of some group external to this. > > :id: 5915c38d-b3c2-4b7c-af76-8a1e002e27f7 > > :setup: standalone instance > > :steps: 1. Enable automember plugin > 2. Add < 500 users, and ensure they are members of a group. > 3. Enable refer-int plugin > 4. Move ou=s1 to a new parent > > :expectedresults: > 1. The plugin is enabled > 2. The users are members of the group > 3. The plugin is enabled > 4. The rename operation of ou=s1 succeeds > """ > > st = topology_st.standalone > > # Create a default group > gps = Groups(st, DEFAULT_SUFFIX) > # Keep the group so we can get it's DN out. > group = gps.create(properties={ > 'cn': 'default_group' > }) > > # Enable automember > amp = AutoMembershipPlugin(st) > amp.enable() > > # Create the automember definition > automembers = AutoMembershipDefinitions(st) > > automember = automembers.create(properties={ > 'cn': 'testgroup_definition', > 'autoMemberScope': DEFAULT_SUFFIX, > 'autoMemberFilter': 'objectclass=nsAccount', > 'autoMemberDefaultGroup': group.dn, > 'autoMemberGroupingAttr': 'member:dn', > }) > > # Enable referint > rip = ReferentialIntegrityPlugin(st) > # We only need to enable the plugin, the default configuration is sane and > # correctly coveres member as an enforced attribute. > rip.enable() > > # Restart to make sure it's enabled and good to go. > st.restart() > > # Now unlike normal, we bypass the plural-create method, because we need control > # over the exact DN of the OU to create. > # Create the ou=account > > # We don't need to set a DN here because ... > ou_account = OrganisationalUnit(st) > > # It's set in the .create step. > ou_account.create( > basedn = DEFAULT_SUFFIX, > properties={ > 'ou': 'account' > }) > # create the ou=int,ou=account > ou_int = OrganisationalUnit(st) > ou_int.create( > basedn = ou_account.dn, > properties={ > 'ou': 'int' > }) > # Create the ou=s1,ou=int,ou=account > ou_s1 = OrganisationalUnit(st) > ou_s1.create( > basedn = ou_int.dn, > properties={ > 'ou': 's1' > }) > > # Create the users 1 -> 1000 in ou=s1 > nsu = nsUserAccounts(st, basedn=ou_s1.dn, rdn=None) > for i in range(1000, 2000): > nsu.create_test_user(uid=i) > > # Assert they are in the group as we expect > members = group.get_attr_vals_utf8('member') > assert len(members) == 1000 > > # Move ou=s1 to ou=account as parent. We have to provide the rdn, > # even though it's not changing. > ou_s1.rename('ou=s1', newsuperior=ou_account.dn) > > members = group.get_attr_vals_utf8('member') > assert len(members) == 1000 > # Check that we really did refer-int properly, and ou=int is not in the members. > for member in members: > assert 'ou=int' not in member > > > > >> >>> >>> Regards >>> >>> Le mer. 20 févr. 2019 à 23:44, William Brown <wbrown(a)suse.de&gt; a écrit : >>> We would need to test this scenario, but it could very likely be a bug in the server. >>> >>> To be sure the conditions you have here are: >>> >>> ou=start,dc=… >>> ou=destination,dc=… >>> >>> In ou=start you have 800+ entries. >>> >>> Then you are doing a modrdn of ou=start to ou=start,ou=destination,dc=…, and the error condition occurs? >>> >>> Is this correct? >>> >>>> On 21 Feb 2019, at 02:49, Olivier JUDITH <gnulux(a)gmail.com&gt; wrote: >>>> >>>> Hi, >>>> >>>> I have activated Referential Integrity plugin on my instance in order to move several OU to a new parent subtree. Also to update automatically uniqueMember attribute defined in group member . >>>> It works fine with few user entries under some OU but fails when the OU contains more than 400 entries or somtime more than 800. >>>> The error from the 389-console is : >>>> ou=UNITA, OU=Accounts,dc=mydomain,dc=com: netscape.ldap.LDAPException: error result (1); Operations error. >>>> In error file >>>> [20/Feb/2019:17:37:59.123749991 +0100] - ERR - ldbm_back_modrdn - SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set SLAPI_RESULT_CODE >>>> >>>> After this error the OU : UNITA, OU=Accounts,dc=mydomain,dc=com is not visible from 389-console . I have to restart the instance in order to recover the OU. >>>> >>>> Did i miss something in my configuration or do i have to set a specific parameter to support big entries ? >>>> >>>> My installation : 389DS 1.3.6 . >>>> _______________________________________________ >>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >>>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>>> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... >>> >>> — >>> Sincerely, >>> >>> William Brown >>> Software Engineer, 389 Directory Server >>> SUSE Labs >>> _______________________________________________ >>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... >>> _______________________________________________ >>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... >> >> — >> Sincerely, >> >> William Brown >> Software Engineer, 389 Directory Server >> SUSE Labs >> > > — > Sincerely, > > William Brown > Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...

On 21 Feb 2019, at 23:28, Olivier JUDITH <gnulux(a)gmail.com&gt; wrote: Hi , After several tests (disable replication /memeberof plugin activated on member and uniquemember attributes) , the problem is not bound to the number of entries . I encounter the same behavior when moving only one account . the problem occurs when an entry is attached to a group (has memberOf attribute). _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...

Okay, I did this with a MMR of two masters, enabled memberOf and did a loop of 20x, and still can’t reproduce this. :( Perhaps it’s a solved problem in 1.4.x, but exists in 1.3.x? > On 22 Feb 2019, at 10:18, William Brown <wbrown(a)suse.de&gt; wrote: > > Okay, I will enable memberOf in the test and try again. Thanks! > >> On 21 Feb 2019, at 23:28, Olivier JUDITH <gnulux(a)gmail.com&gt; wrote: >> >> Hi , >> >> After several tests (disable replication /memeberof plugin activated on member and uniquemember attributes) , the problem is not bound to the number of entries . I encounter the same behavior when moving only one account . the problem occurs when an entry is attached to a group (has memberOf attribute). >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... > > — > Sincerely, > > William Brown > Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...