Michael Ströder wrote:
Howard Chu wrote:
One crucial step in isolating the problem would be to determine if the error actually occurs during slapadd or slapcat.
I revise my statement that data looks ok via LDAP. Messing up the data seems to happen during slapadd if the LDIF is not in tree order (as already suspected in a former posting which was not read I guess).
Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is in tree order while in data1.ldif subordinate entries come before their superior entries (which is what slapcat sometimes produce).
Interestingly enough, my results differed from yours. Also the results differed depending on whether I slapadd'd the bare LDIF, or an LDIF with all operational attributes included. But this is now fixed in git master. Given this and the typos in back-sql it appears we should scratch 2.4.27 and push a new release.
These entries
dn: ou=Groups,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Groups
dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local cn: slapd-1 objectClass: applicationProcess objectClass: simpleSecurityObject userPassword: pw_slapd1
get mixed into that:
dn: ou=Groups,ou=schulung,dc=stroeder,dc=local cn: slapd-1 hasSubordinates: TRUE objectClass: applicationProcess objectClass: simpleSecurityObject userPassword: pw_slapd1