Re: openldap 2.4(slave) replication to openldap2.3(provider not working

I have modified my slapd.conf file on consumer 2.4

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
#include /usr/share/doc/krb5-server-ldap-1.9/kerberos.schema
#include /usr/share/doc/sudo-1.8.5-1.el6/schema.OpenLDAP

# Primary database.
database bdb
directory /var/lib/ldap
suffix "dc=kinect,dc=co,dc=nz"
rootdn "cn=Manager,dc=kinect,dc=co,dc=nz"
rootpw {SSHA}vO/5mpk4CMOKDelv36BpjksRaHFjgqh1
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args

# syncrepl specific indices
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub
index entryUUID                               eq
index entryCSN                                eq

# syncrepl directives
syncrepl        rid=3
                provider=ldap://testaaa-int.dcnztest.co.nz:389
                bindmethod=simple
                starttls=no
                binddn="cn=sync,dc=kinect,dc=co,dc=nz"
                credentials="ieLeik8v"
                searchbase="dc=kinect,dc=co,dc=nz"
                logbase="cn=accesslog"
                schemachecking=off
                type=refreshAndPersist
                retry="05 +"
                syncdata=accesslog

# Refer updates to the master
updateref       ldap://testaaa-int.dcnztest.co.nz

access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage

access to attrs=userPassword by self write by * auth

access to dn.base=dc=kinect,dc=co,dc=nz by * search
by * none

# Give access to this database to serveral important users.
#to dn.subtree="dc=kinect,dc=co,dc=nz"

access to attrs=userPassword
        by dn.exact="cn=sync,dc=kinect,dc=co,dc=nz" read
        by dn.exact="uid=client-root,ou=auth,dc=kinect,dc=co,dc=nz" write
        by self write
        by anonymous auth
        by * none

# default allow all
access to *
        by self write
        by users read
        by anonymous read

TLSCACertificateFile /etc/openldap/tls/test02aaa.pem
TLSCertificateFile /etc/openldap/tls/test02aaa.pem
TLSCertificateKeyFile /etc/openldap/tls/test02aaa-key.pem

database monitor

access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by dn.base="cn=admin,dc=kinect,dc=co,dc=nz" manage
by * none

# Configure the config backend.

database config

# Again, let SASL EXTERNAL users with UID 0 & GID 0 users and the rootdn manage
# the configuration. But not any other users.
access to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by dn.base="cn=admin,dc=kinect,dc=co,dc=nz" manage
by * none

Then run

#slapcat -f ldap/slap.conf.consumer -F /tmp/ldap -n 0

#cp -rp ldap/cn\=config* /etc/openldap/slapd.d/

#chown -R ldap:ldap /etc/openldap/slapd.d

#slaptest -uF /etc/openldap/slapd.d

#/etc/init.d/slapd start

Now it comes up with a different error

Mar 20 11:52:31 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003 mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:31 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:36 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003 mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:36 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:41 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003 mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:41 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:46 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003 mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:46 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:51 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003 mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:51 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:56 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003 mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:56 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying

This is the value of objectclass in /etc/openldap/slapd.d/

/root@vm-nix-t01 tmp]# grep -iR objectclass /etc/openldap/slapd.d/*
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:objectClass: olcDatabaseConfig
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:objectClass: olcBdbConfig
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif: objectclass=*)" searchbase="dc=kinect,dc=co,dc=nz" logbase="cn=accesslog" sco
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:olcDbIndex: objectClass pres,eq
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:structuralObjectClass: olcBdbConfig
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:objectClass: olcSchemaConfig
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier: olmObjectClasses 1.3.6.1.4.1.4203.666.3.16
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier: olmSubSystemObjectClasses olmObjectClasses:0
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier: olmGenericObjectClasses olmSubSystemObjectClasses:0
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier: olmDatabaseObjectClasses olmSubSystemObjectClasses:1

Any suggestions

On 18 March 2014 18:40, Philip Guenther <pguenther@proofpoint.com> wrote:

On Mon, 17 Mar 2014, Andrew Belford wrote:
> I have just registered on the mail list seeking for assistance of how to
> get openldap replication working between 2.3 and 2.4 openldap.

Time to read the "Changes Since Previous Release" section of the 2.4 admin
guide:
http://www.openldap.org/doc/admin24/appendix-changes.html

> My provider is running on 2.3(openldap) which replicates successfully
> to a 2.3(openldap slave). Recently we build a rhel6 host that comes
> with openldap 2.4 with the intention to run openldap on it as slave.
>
> I have stand up the new slave(2.4 openldap) using the same configuration of
> the other running slave(2.3openldap)
> I have managed to slapadd the ldif of the master to the new slave
> slapadd -l /tmp/AAA01_20140314.ldif
>
> However, if I try and search for entries, it shows the following but I am
> expecting 32K objects

Item B.2 at
http://www.openldap.org/doc/admin24/appendix-upgrading.html
?

> I also don't see any replication details in /var/log/slapd.log

Since you don't mention how you configured replication to this 2.4 box or
what output you were expecting, I can't help on this.

Philip Guenther