> On 28 Aug 2020, at 19:23, Ludwig Krispenz <krispenz@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
