[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OL 2.1.2 - "no structuralObjectClass operational attribute"

"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> writes:

> You might try OPENLDAP_REL_ENG_2, it includes a error reporting
> bug fix.  2.1.2 catches the more schema errors than 2.0 but
> slapadd(8) provides the wrong error text.  IRRC, ldapadd(1)
> reports the correct error text.

OK I tried ldapadd(1) as you recomanded.

/usr/local/test/bin/ldapadd -x -W -D "cn=ldapadm,dc=crol,dc=net" < blah
Enter LDAP Password: 
adding new entry "cn=layers,ou=Rpc,dc=crol,dc=net"
ldapadd: update failed: cn=layers,ou=Rpc,dc=crol,dc=net
ldap_add: Object class violation (65)
	additional info: no structuralObjectClass operational attribute

This was first entry in ldif(5) file exported from 2.0.23:

dn: cn=layers,ou=Rpc,dc=crol,dc=net
oncRpcNumber: 100121
description: RPC layers
description: ONC RPC number 100121 (layers)
objectClass: oncRpc
objectClass: top
cn: layers
cn: na.layers
creatorsName: cn=root,dc=crol,dc=net
createTimestamp: 20010707132849Z
modifiersName: cn=root,dc=crol,dc=net
modifyTimestamp: 20010707132849Z

Then I deleted that entry. Next entry was this:

/usr/local/test/bin/ldapadd -x -W -D "cn=ldapadm,dc=crol,dc=net" < eax 
Enter LDAP Password: 
adding new entry
ldapadd: update failed:
ldap_add: Invalid DN syntax (34)
	additional info: invalid DN

This was second entry ...

dn: sendmailMTAKey=crol.net,sendmailMTAMapName=mailer,smhost=crolvax,cn=Sendmai
objectClass: sendmailMTA
objectClass: sendmailMTAMap
objectClass: sendmailMTAMapObject
sendmailMTAMapName: mailer
sendmailMTAKey: crol.net
sendmailMTAMapValue: esmtp:[click.crol.net]
creatorsName: cn=root,dc=crol,dc=net
createTimestamp: 20010708151723Z
sendmailMTAHost: crolvax.crol.net
modifiersName: cn=root,dc=crol,dc=net
modifyTimestamp: 20010708152610Z

> Make sure your object entries have one structural object class
> which is superior to all other structural object classes listed.

I tried with this:

objectClass ( STRUCTURAL
        NAME 'handler'
        DESC 'ne jebi nego dodaj entry !!!' )

and added "objectClass: handler" to the first entry (see above).

Same thing ... no structuralObjectClass operational attribute.

I was proud about my LDAP server, I have schema checking on in 2.0.23,
and it works perfectly without one warning. I was thinking I'm doing
right thing, but now it looks like my LDAP database was one big error
- without even one single _correct_ entry ... :-(

I cannot add even this little entry:

dn: ou=Servers,dc=crol,dc=net
dc: crol
objectClass: organization
objectClass: dcObject
o: CRoL

no structuralObjectClass ...

What I'm doing wrong? If I'm not doing nothing wrong, can I have old
"flexible" schema behaviour in OpenLDAP 2.1.X ?

This signature intentionally left blank