On 21 Feb 2019, at 13:12, William Brown <wbrown(a)suse.de>
wrote:
> On 21 Feb 2019, at 08:57, Olivier JUDITH <gnulux(a)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(a)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(a)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(a)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(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