Referential Integrity and moving subtree to another parent fails

[Olivier JUDITH]

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 .

[William Brown]

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/[e-mail]... 
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

[Olivier JUDITH]

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.

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/[e-mail]...
>
>  —
>  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/[e-mail]...
>

[William Brown]

>  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/[e-mail]...
>  
>  —
>  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/[e-mail]...
>  _______________________________________________
>  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/[e-mail]... 
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

[William Brown]

>  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/[e-mail]...
> > 
> > —
> > 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/[e-mail]...
> > _______________________________________________
> > 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/[e-mail]...
>  
>  —
>  Sincerely,
>  
>  William Brown
>  Software Engineer, 389 Directory Server
>  SUSE Labs
>   
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

[William Brown]

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/[e-mail]...
> >> 
> >> —
> >> 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/[e-mail]...
> >> _______________________________________________
> >> 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/[e-mail]...
> > 
> > —
> > 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/[e-mail]... 
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

[Olivier JUDITH]

Hi Williams

Can you check with MMR topology and memberOf plugin activated. Also i use
uniqueMember instead of member for groups.

Regards


Le jeu. 21 févr. 2019 à 05:19, William Brown <wbrown(a)suse.de&gt; a écrit :

>  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/[e-mail]...
>  >>>
>  >>> —
>  >>> 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/[e-mail]...
>  >>> _______________________________________________
>  >>> 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/[e-mail]...
>  >>
>  >> —
>  >> 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/[e-mail]...
>
>  —
>  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/[e-mail]...
>

[Olivier JUDITH]

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).

[William Brown]

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/[e-mail]... 
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

[William Brown]

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/[e-mail]...
>  
>  —
>  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/[e-mail]... 
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

[Alberto Viana]

I'm facing a very similar problem, my version:
389-Directory/1.3.7.4.20170912git26a9426

So, it's probably you right, maybe It's a 1.3.x problem.

In my case, I disabled the plugin until I can upgrade my 389 version.

On Fri, Feb 22, 2019 at 1:07 AM William Brown <wbrown(a)suse.de&gt; wrote:

>  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/[e-mail]...
>  >
>  > —
>  > 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/[e-mail]...
>
>  —
>  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/[e-mail]...
>

[William Brown]

>  On 27 Feb 2019, at 23:41, Alberto Viana <albertocrj(a)gmail.com&gt;
> wrote:
>  
>  I'm facing a very similar problem, my version:
>  389-Directory/1.3.7.4.20170912git26a9426
>  
>  So, it's probably you right, maybe It's a 1.3.x problem. 
It’s still a problem though. I just don’t have the setup to build/test 1.3.x anymore.
Maybe Mark can help out here, I think he probably has a 1.3.x build around? The refint
modrdn test case was merged in pagure, so maybe we could backport to 1.3.x and test? 

>  
>  In my case, I disabled the plugin until I can upgrade my 389 version.  
>  
>  On Fri, Feb 22, 2019 at 1:07 AM William Brown <wbrown(a)suse.de&gt; wrote:
>  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/[e-mail]...
>  > 
>  > —
>  > 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/[e-mail]...
>  
>  —
>  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/[e-mail]...
>  _______________________________________________
>  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/[e-mail]... 
—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs