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

RE: (ITS#4846) attribute 'objectClass' provided more than once



Hello Howard,

i'm surely using slurpd. The replication part in slapd.conf of the master is:

replogfile      /home/ldap/de/secartis.replog
replica         uri=ldap://10.36.125.15:389
                bindmethod=simple
                binddn="cn=admin,o=secartis,c=de"
                credentials=secartis
                attrs!=structuralObjectClass
                attrs!=entryUUID
                attrs!=creatorsName
                attrs!=createTimestamp
                attrs!=entryCSN
                attrs!=modifiersName
                attrs!=modifyTimestamp

i.e. i'm using the root account for replication. And that's the mistake. I changed the binddn to a user account and now it works.

Thanks a lot
Kind Regards Wolfgang

-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com]
Sent: Wed 2007-02-21 14:20
To: Christ, Wolfgang
Cc: openldap-its@openldap.org
Subject: Re: (ITS#4846) attribute 'objectClass' provided more than once
 
wolfgang.christ@secunet.com wrote:
> Full_Name: Wolfgang Christ
> Version: 2.3.32
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (213.68.205.167)
> 
> 
> I'm trying to replicate an OpenLDAP DB using slurpd. But even a simple ldapadd
> with an LDIF file like this:
> 
> dn: cn=wolfgang,ou=organization unit,o=organization,c=de
> objectClass: inetOrgPerson
> objectClass: person
> cn: wolfgang
> sn: hilfe
> userCertificate;binary:< file:///cert.crt
> 
> OpenLDAP returns an error "attribute 'objectClass' provided more than once". If
> I
> remove the second objectclass with certificate and and add these in a seperate
> modify step, everything is fine.
> 
> If i modify "servers/slapd/add.c" in line 318:
> 
> /* check for unmodifiable attributes */
> /*rs->sr_err = slap_mods_no_repl_user_mod_check( op,
> modlist, &rs->sr_text, textbuf, textlen );
> if ( rs->sr_err != LDAP_SUCCESS ) {
>   send_ldap_result( op, rs );
>   goto done;
> }*/
> 
> and prevent calling of slap_mods_no_repl_user_mod_check(), replication works.
> 
> Could you explain, what is the sense of slap_mods_no_repl_user_mod_check()
> and why it causes slurpd not to work.

Your post makes no sense. That function is only called when a normal user is 
trying to add an entry. It is skipped when the replication user is doing the 
add. So this should have nothing to do with slurpd.

What are you using to perform the Add operation? Certainly OpenLDAP's ldapadd 
tool won't generate an error like this; it can only arise because of a 
malformed Add request packet.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   Chief Architect, OpenLDAP     http://www.openldap.org/project/