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

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

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

— 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.... _______________________________________________ 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....

— Sincerely,

William Brown Software Engineer, 389 Directory Server SUSE Labs

— Sincerely,

William Brown Software Engineer, 389 Directory Server SUSE Labs

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

...

...

...

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

...

...

...

---

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

...

...

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

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

Okay, I will enable memberOf in the test and try again. Thanks!

On 21 Feb 2019, at 23:28, Olivier JUDITH gnulux@gmail.com 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@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....

— Sincerely,

William Brown Software Engineer, 389 Directory Server SUSE Labs

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@suse.de 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@suse.de wrote:

Okay, I will enable memberOf in the test and try again. Thanks!

...

On 21 Feb 2019, at 23:28, Olivier JUDITH gnulux@gmail.com 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@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....

...

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

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