[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

On 01/02/2012 10:38, Jephte CLAIN wrote:
On 01/02/2012 08:47, Jephte CLAIN wrote:
On 27/01/2012 17:33, Jephte CLAIN wrote:
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 :-)


I kinda have a chicken and egg problem here: with slapadd, I cannot
define an acl with a DN that is not existing

I mean, I define acls on the frontend to enable syncrepl replication.
I have to seed olcDatabase={-1}frontend to have the initial acls,
because like the two other, it is not replicated, because the frontend
on the consumer is newer than the one on the provider.

So, I have on the provider:

dn: olcDatabase={-1}frontend,cn=config
olcAccess: {1}to * by dn.exact="cn=syncrepl,dc=univ-reunion,dc=fr"
manage by * break

When I try to slapadd it on the empty consumer, I get:

4f28d8ef /etc/ldap/slapd.d: line 1: bad DN
"cn=syncrepl,dc=univ-reunion,dc=fr" in by DN clause

It does not work because cn=syncrepl,dc=univ-reunion,dc=fr does not
exist yet. And I cannot add it later, because as a replica, it cannot be

... what can I do?
Perhaps I just can't setup the consumer properly? Am I the only one to
hit this "bug"?

The workaround is simple: each time I setup a consumer, refresh the
entries on the master to force the replication with the current content,
but this is awkward

Ok, talking to myself on the list since this morning :-)

I ended up doing like this:

- seed the consumer with a super-mininal initial ldif like the following:
------------- 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://provider.tld/";
  bindmethod=simple binddn=cn=config credentials=password
  type=refreshAndPersist retry="60 10 300 +" schemachecking=off
------------- 8< -------------
- start the consumer
- then "touch" the objects on the provider, to force their replication:

ldapmodify -H ldap://provider.tld -x -D cn=config -w password <<EOF
dn: cn=config
changetype: modify

dn: olcDatabase={-1}frontend,cn=config
changetype: modify

dn: olcDatabase={0}config,cn=config
changetype: modify

so far, it's working as intended

Looking forward for the answers to my previous questions though.
And: is it a bug, or a feature? is this the only (intended) to do it?

best regards,

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