On 28 Aug 2020, at 19:23, Ludwig Krispenz
<krispenz(a)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.
>
> Thanks!
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs