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).
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
Bug-hunting takes systematic, methodical testing. You can't just go changing revisions willy-nilly.
You don't have to teach me anything in the testing field.
Clearly I *do* need to, based on the completely useless content-free emails you've posted so far.
Again: Your arrogant attitude does not help at all. It solely frustrates people who are trying to help even if they don't have much spare time left.
The only person copping an attitude here is you. I'm simply asking you for information that would help point to the problem; you're choosing to ignore my questions until I make a point of re-asking.
Thank you for the test data.