Gavin Henry wrote:
<quote who="Michael Steinmann">
On Thu, January 18, 2007 12:53 pm, Gavin Henry wrote:
Michael Steinmann said the following on 12/01/07 10:03:
I'm currently using ppolicy in a replicated 2.3.30 environment. Most things wrt ppolicy work extremely well but I'm having issues with slurpd and ppolicy's internal attributes.
Due to firewall restrictions I'm currently forced to use both syncrepl and slurpd for replication. Problem with slurpd is, that when a user changes her password the pwdHistory attribute gets replicated with an add/delete MOD. All attributes get replicated OK but I still get errors both on the master and on the slave.
Have you tried using Syncrepl RefreshOnly to help with firewall issues?
Gavin
yes, but according to [1] and other sources the current implementation of refreshAndPersist is not a pure push solution. It's still the slave that initiates the connection. To me it looked as I'd have to wait for 2.4.
Correct me if I'm wrong as I might misinterpret the docs, however. Have you tested this and confirmed it works?
No, you are right. I misunderstood your requirement for a push based solution.
My apologies.
no problem. After reading the description I myself was under the impression that I could do syncrepl in both directions (firewall-wise).
Out of interest, what are your firewall configurations like? Maybe we are missing some detail?
The master is in an internal net, the slave is in a DMZ (tcp/389, starttls, iptables fw, only outbound connections, nothing special). 'Business' rule is: all connections must be initiated from the inside to the DMZs, no incoming new connections from a DMZ to an internal net.
We're replicating part of the tree from the master to the 'primary' slave in the DMZ. There's a second slave in the DMZ that does syncrepl with the primary slave. The slaves do authentication for web/app servers.
-- mike