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
