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 <wbr...@suse.de> a écrit :
> Sorry, this formatted, poorly. Find attached,
>
>
>
> > On 21 Feb 2019, at 14:17, William Brown <wbr...@suse.de> wrote:
> >
> >
> >
> >> On 21 Feb 2019, at 13:12, William Brown <wbr...@suse.de> wrote:
> >>
> >>
> >>
> >>> On 21 Feb 2019, at 08:57, Olivier JUDITH <gnu...@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 <will...@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 <wbr...@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 <gnu...@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-le...@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-le...@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-le...@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-le...@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-le...@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-le...@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
