On 31.08.20 02:33, William Brown wrote:
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.
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@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
_______________________________________________
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
