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

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

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 :-)
>
> Hello,
>
> 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
> modified
>
> ... 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/";
  searchbase=cn=config
  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
EOF

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