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