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

structuralObjectClass issues between master and slave servers



Hello,

I'm encountering an odd issue, whereby if I add an LDAP entry to our master LDAP server and the entry contains an attribute specifying which objectClass is the structuralObjectClass, then the server won't add it, and exits with an error. Yet the exact opposite happens when adding the test entry to any slave or standalone server. The LDIF test file is as follows:

dn: cn=bobdobbs,ou=People,dc=test,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: bobdobbs
sn: dobbs
structuralObjectClass: inetOrgPerson

When I add this using ldapadd on the master LDAP server, it exits with the following error:

adding new entry "cn=bobdobbs,ou=People,dc=test,dc=com"
ldapadd: update failed: cn=bobdobbs,ou=People,dc=test,dc=com
ldap_add: Constraint violation (19)
       additional info: structuralObjectClass: no user modification allowed

When I remove the 'structuralObjectClass' attribute, it adds just fine. When this file is added directly to any of the slave servers, or to my personal workstation server, which is a standalone that does not slave or replicate, it adds fine WITH the 'structuralObjectClass' attribute defined. However, if I remove that line, it exits with the following error:

adding new entry "cn=bobdobbs,ou=People,dc=test,dc=com"
ldapadd: update failed: cn=bobdobbs,ou=People,dc=test,dc=com
ldap_add: Internal (implementation specific) error (80)
       additional info: no structuralObjectClass operational attribute

So basically, the master server fails if that line is present, and slave or standalone servers fail if that line is not present. All are running openldap 2.1.25 on RH9. The slave slapd.conf files are identical to the master slapd.conf file minus the replication directives. Any insight would be greatly appreciated. Many thanks.

Peter