On 31.08.20 02:33, William Brown wrote:
>
>> On 28 Aug 2020, at 19:23, Ludwig Krispenz <krispenz@t-online.de> wrote:
>>
>>
>> On 27.08.20 04:01, William Brown wrote:
>>> Hey there,
>>>
>>> I'm seeing some odd behaviour in an import test. I'm seeing that a large number of entries won't import unless the directory is restarted before the import task is performed.
>>>
>>> The error appears to be:
>>>
>>> [25/Aug/2020:14:14:58.973490600 +1000] - WARN - import_foreman - import userRoot: Skipping entry "cn=group0,ou=Groups,dc=example,dc=com" which has no parent, ending at line 154 of file "/opt/dirsrv/var/lib/dirsrv/slapd-standalone1/ldif/4f8afb8d-ec97-4246-94a2-ec343c0eacb4.ldif"
>>> ...
>>> [25/Aug/2020:14:14:59.307477400 +1000] - INFO - bdb_import_main - import userRoot: Import complete. Processed 14 entries (10 were skipped) in 1 seconds. (14.00 entries/sec)
>>>
>>>
>>> This is where a newly created backend *with* example entries, then has it's entire content overwriten during an import. Anything that is underneath the ou=* entries is not imported, but the ou= and dc=are fine.
>>>
>>> I'm wondering if this is something related to the fact we are replacing the ou= entries with different ids/nsunique ids. IE
>>>
>>> id 3
>>> rdn: ou=groups
>>> objectClass: top
>>> objectClass: organizationalunit
>>> ou: groups
>>> aci: (targetattr="cn || member || gidNumber || nsUniqueId || description || ob
>>> jectClass")(targetfilter="(objectClass=groupOfNames)")(version 3.0; acl "Enab
>>> le anyone group read"; allow (read, search, compare)(userdn="ldap:///anyone")
>>> ;)
>>> aci: (targetattr="member")(targetfilter="(objectClass=groupOfNames)")(version
>>> 3.0; acl "Enable group_modify to alter members"; allow (write)(groupdn="ldap:
>>> ///cn=group_modify,ou=permissions,dc=example,dc=com");)
>>> aci: (targetattr="cn || member || gidNumber || description || objectClass")(ta
>>> rgetfilter="(objectClass=groupOfNames)")(version 3.0; acl "Enable group_admin
>>> to manage groups"; allow (write, add, delete)(groupdn="ldap:///cn=group_admi
>>> n,ou=permissions,dc=example,dc=com");)
>>> creatorsName: cn=directory manager
>>> modifiersName: cn=directory manager
>>> createTimestamp: 20200827015033Z
>>> modifyTimestamp: 20200827015033Z
>>> nsUniqueId: b0fce42b-e80711ea-8141c872-2df18128
>>> parentid: 1
>>> entryid: 3
>>> numSubordinates: 1
>>>
>>> Becomes:
>>>
>>> id 4
>>> rdn: ou=Groups
>>> createTimestamp: 20200224023755Z
>>> creatorsName: cn=Manager,dc=example,dc=com
>>> entryUUID: 67cc2212-eafa-1039-8830-152569770969
>>> modifiersName: cn=Manager,dc=example,dc=com
>>> modifyTimestamp: 20200224023755Z
>>> objectClass: organizationalUnit
>>> objectClass: top
>>> ou: Groups
>>> nsUniqueId: 87b64988-e68911ea-a943c898-6d74ab17
>>> parentid: 1
>>> entryid: 4
>>>
>>>
>>> Given that these id's are changing I'm wondering if this is somehow breaking our import ordering? Any ideas on where I should start to investigate this?
>> shouldn't the nsuniqueid be preserved ? Otherwise you could not use import to initilaize a replica.
> The use case that's happening is that after a backend is setup with sample entries, then you try to restore from a backup or ldif of different origin. So the nsunique and entryid's both could and probably will change in this case.
yes, but what Imean is that if the entry in the ldif contains a
nsuniqueid it should be used
>
>
>>> Thanks!
>>>
>>> —
>>> Sincerely,
>>>
>>> William Brown
>>>
>>> Senior Software Engineer, 389 Directory Server
>>> SUSE Labs
>>> _______________________________________________
>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>> _______________________________________________
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
No comments:
Post a Comment