[Date Prev][Date Next]
Re: Replication errors with slurpd and ppolicy
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
>>>> 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?
>> yes, but according to  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
> 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.