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