Great ! it finally work :-)
I've just compiled RPMS under RH 8.0 , I put them + source RPM in :
http://www.int-evry.fr/mci/user/procacci/SRPMS/ -> openldap-2.1.13-3
Thanks to Frank Swasey an openldap developpers it now includes the patch
about schema checking problem with attributes in rdn not present in
entry which caused a seg fault message !
%changelog
* Thu Feb 28 2003 Jehan Procaccia <jehan.procaccia@int-evry.fr> 2.1.13-3
- from Francis Swasey <Frank.Swasey@uvm.edu> 2.1.12-uvm2.8.0:
- sleepycat bdb 4.1.25 plus locking patch
- add patch for schema-check
- add patch for slapd lock-release in group acl processing
- add patch for slapcat a subtree
- add make test to openldap build
Now insteed of seg fault it says:
<= str2entry(cn=brou,ou=People,dc=enstb,dc=fr) -> 0x823aba0
...
slapadd: dn="cn=brou,ou=People,dc=enstb,dc=fr" (line=19): (16) value of
naming attribute 'cn' is not present in entry
ldif beeing:
dn: cn=brou,ou=People,dc=enstb,dc=fr
cn: Jean Brou
sn: Brou
objectClass: top
objectClass: person
objectClass: inetOrgPerson
mail: Jean.Brou@enstb.fr
givenName: Jean
now if I put in the ldif:
sn=brou,ou=People,dc=enstb,dc=fr
<= index_entry_add( 3, "sn=brou,ou=People,dc=enstb,dc=fr" ) success
:-)
However the error message could be even more explicit :
"(16) value of naming attribute 'cn' is not present in entry" + add " or
does not have the same value in the entry than in the dn ..." which was
my case !.
By the way, why this new contraint ? in respect to LDAP RFCs ?
Thanks.
Frank Swasey wrote:
Today at 6:30pm, Pierangelo Masarati wrote:
Thanks!
I'm rebuilding now with that patch applied to schema_check.c.
I am curious about what part of the schema I am violating that was
legal
(or possibly just not checked) in 2.1.12. But, time will tell -- slow
machine takes a while to build the RPM :-)
OpenLDAP never checked that the attributeTypes and values used
in the RDN were actually present in the entry. This was added
in 2.1.13 (maybe it was not adequately advertised ...).
For details, you may follow the thread originated by ITS#2243.
Well, my ldif file isn't supposed to have any entries that violate
that.... but looking at that one entry.... Drat! more crud to go
fix... :-)
Thanks,
F