Re: Odd behaviour in import

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

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




[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux