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 <[email protected]> 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
>
