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
