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@suse.de> a écrit :
Sorry, this formatted, poorly. Find attached,



> On 21 Feb 2019, at 14:17, William Brown <wbrown@suse.de> wrote:
>
>
>
>> On 21 Feb 2019, at 13:12, William Brown <wbrown@suse.de> wrote:
>>
>>
>>
>>> On 21 Feb 2019, at 08:57, Olivier JUDITH <gnulux@gmail.com> 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@blackhats.net.au>
> # 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@suse.de> 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@gmail.com> 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@lists.fedoraproject.org
>>>> To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
>>>
>>> —
>>> Sincerely,
>>>
>>> William Brown
>>> Software Engineer, 389 Directory Server
>>> SUSE Labs
>>> _______________________________________________
>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
>>> _______________________________________________
>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
>>
>> —
>> 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@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@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.fedoraproject.org


Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs

_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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.fedoraproject.org