[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Replication errors with slurpd and ppolicy
<quote who="Michael Steinmann">
> 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).
I think we are both wrong now:
http://www.openldap.org/lists/openldap-software/200701/msg00176.html
http://www.openldap.org/lists/openldap-software/200701/msg00181.html
>
>
>> 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.
Understood. If the worst came to worse, you could only allow IPSEC tunnels
in and out, cert based etc. Then your firewall only lets NEW IPSEC
connections out. That should be still secure.
>
> 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.
The primary slave being the slurpd pushed to one?
>
> --
> mike
>
>