On 27/01/2012 17:33, Jephte CLAIN wrote:

hello,

I'm new on this list. I use OpenLDAP 2.4.23 on debian squeeze

Hello,

Following the advice from Michael Ströder, I tried with OpenLDAP 2.4.28

By the way, I ported the openldap-2.4.28 package from wheezy to squeeze, and made source and binary packages. they are available on http://wapps.univ-reunion.fr/openldap-files/ There are minimal instructions to build them yourself, but it's in french (sorry). Also, it's totally unsupported, but you already did know that, didn't you :-)

It seems that the problem is still there with openldap-2.4.28. The log says:

4f28bfdf syncrepl_entry: rid=000 be_add cn=config (68) 4f28bfdf dn_callback : new entry is older than ours cn=config ours 20120201043021.553920Z#000000#000#000000, new 20120131114804.777497Z#000000#000#000000 4f28bfdf syncrepl_entry: rid=000 entry unchanged, ignored (cn=config)

4f28bfdf syncrepl_entry: rid=000 be_add olcDatabase={-1}frontend,cn=config (68) 4f28bfdf dn_callback : new entry is older than ours olcDatabase={-1}frontend,cn=config ours 20120201043021.554303Z#000000#000#000000, new 20120131114801.967340Z#000000#000#000000 4f28bfdf syncrepl_entry: rid=000 entry unchanged, ignored (olcDatabase={-1}frontend,cn=config)

4f28bfdf syncrepl_entry: rid=000 be_add olcDatabase={0}config,cn=config (68) 4f28bfdf dn_callback : new entry is older than ours olcDatabase={0}config,cn=config ours 20120201043021.554194Z#000000#000#000000, new 20120131114801.503432Z#000000#000#000000 4f28bfdf syncrepl_entry: rid=000 entry unchanged, ignored (olcDatabase={0}config,cn=config)

This is not working as documented, isn't it? For now, I will seed the consumer with an export of the two objects cn=config and olcDatabase={0}config,cn=config from the master. even though they are not updated, it will not be problem because the consumer will already be up to date :-)

However, my initial question remains:

My goal is to replicate schemas, indexes, limits, acls and Authz definitions. I thought that a whole replica would the easiest. How do you guys do this at your sites? Is it possible/advisable to only replicate a subset of cn=config?

I've got one more question: I'm not sure about the meaning of rid in 'slapd -c'. it's the replication id from the consumer side pov, ok?

so, suppose the master has

------------- 8< ------------- dn: olcDatabase={0}config,cn=config ... olcSyncrepl: {0}rid=0 provider="ldap://master.tld/" searchbase=cn=config bindmethod=simple binddn=cn=config credentials=password type=refreshAndPersist retry="60 10 300 +" schemachecking=off ------------- 8< -------------

and the consumer seed is:

------------- 8< ------------- dn: olcDatabase={0}config,cn=config ... olcSyncrepl: {0}rid=999 provider="ldap://master.tld/" searchbase=cn=config bindmethod=simple binddn=cn=config credentials=password type=refreshAndPersist retry="60 10 300 +" schemachecking=off ------------- 8< -------------

Should I start slapd with -c "rid=999" or -c "rid=0" ? From what I understand, I would ulse -c "rid=999", it would replicate cn=config and replace (if it was working) the "rid=999..." attribute value with the "rid=0..." one. Did I understand correctly?

Thank in advance for your clarifications have a good day. regards, jephté

I'm currently testing full replication with the small configuration seed on the consumer side, but the replication is not complete.

Let me explain in details:

so, the consumer starts with no data at all (I wipe /etc/ldap/slapd.d/* files, and /var/lib/ldap/*)

Based on the test049, I do 'slapadd -F /etc/ldap/slapd.d -b cn=config -l initial.ldif' with initial.ldif as:

------------- 8< ------------- dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcSyncrepl: {0}rid=0 provider="ldap://master.tld/" searchbase=cn=config bindmethod=simple binddn=cn=config credentials=password type=refreshAndPersist retry="60 10 300 +" schemachecking=off ------------- 8< -------------

on the provider side, cn=config is the rootdn of cn=config

so the database cn=config is replicated, except for the above objects. Indeed, the logs says:

dn_callback : new entry is older than ours cn=config ours 20120127114737.207735Z#000000#000#000000, new 20120127112957.179717Z#000000#000#000000 dn_callback : new entry is older than ours olcDatabase={0}config,cn=config ours 20120127114737.207985Z#000000#000#000000, new 20120127112953.813862Z#000000#000#000000

and this makes sense. I searched the archives, and found a message from Howard Chu made on 19 Apr 2011:

------------- 8< ------------- ... Use slapd -c. Read the slapd(8) manpage. ------------- 8< -------------

The manpage says:

------------- 8< ------------- -c cookie (...) Use only the rid part to force a full reload. ------------- 8< -------------

So I tried '/usr/sbin/slapd -c "rid=0" -d 16384 ...' but I got the message above about the entry not overwritten because of the timestamp. I wonder what I am doing wrong...

I'd prefer not to have to use a more recent version, because debian already does a good job following the patches and keeping the whole thing stable :-) But If this is a known issue, what are my options?

I mean, my goal is to replicate schemas, indexes, limits, acls and Authz definitions. I thought that a whole replica would the easiest.