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
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/