Re: making a full replica: slapd -c "rid=xxx" doesn't seem to work

[Jephte CLAIN <Jephte.Clain@univ-reunion.fr>]

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.


--
cordialement,
Jephté Clain
Direction des Systèmes d'Information
et des Usages Numériques - 2IG
Tél. 0262 93 86 31
Fax. 0262 93 81 06