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

Re: OpenLDAP ACLs Question



On Thursday, 15 April 2010 21:18:13 Tim Gustafson wrote:
> Hi,
> 
> We have three OpenLDAP servers: 10.0.0.2, 10.0.0.3 and 10.0.0.4 and one web
>  server 10.0.0.5.

How is replication configured? Single master and multiple replicas 
synchronising off it (which is the master)? MMR or cascading replication 
(provide a diagram or description)?

>If we change

I assume "change" implies restarting slapd ...

>the last access clause to this:

[...]

> then the user self-updates are replicated properly.  Note that 10.0.0.5 is
>  the *web server*.  The way I read this ACL, it means we're granting read
>  access to the web server, and in so doing, the other two LDAP servers
>  (10.0.0.3 and 10.0.0.4) are magically able to replicate data again.

So, adding an irrelevant ACL, *and* restarting slapd causes the replication to 
resume? So, when this occurs, have you tested just restarting slapd?

> When replication is *not* working in this set-up, re-starting slapd on
>  10.0.0.3 and 10.0.0.4 (without changing any ACLs anywhere) causes them to
>  suck down all the updates they missed before.

So, if the ACLs are not modified, but the a restart of slapd forces 
replication, why would this be an ACL issue(or did I misunderstand this 
sentence)?

Maybe instead you should post your replication configuration?

Note, there are some still some reliability issues (IMHO) with syncrepl, in 
that it doesn't always handle connection failures without manual intervention. 
If these are fixed (I haven't been able to test them myself) in 2.4.x, they are 
probably still present in 2.3.x. For example, a firewall in between provider 
and consumer with infrequent changes where the firewall drops idle connections 
and the hosts have incorrect keepalives set would result in replication 
failures with refreshAndPersist.

> I'm not really asking anyone to fix the problem or to offer a solution to
>  the problem...I just want to know if this sort of replication issue was a
>  known problem in the past?

You don't post anything related to your replication configuration when asking 
about a replication failure, so it is difficult to provide any more information.

Regards,
Buchan