[Freeipa-users] Need for some pull-style replication, or an alternate solution

[Ludwig Krispenz]

On 08/20/2014 02:55 PM, Petr Spacek wrote:
> On 20.8.2014 10:58, Dmitri Pal wrote:
>> On 08/19/2014 07:55 PM, Joshua J. Kugler wrote:
>>> A replica must connect to the master for initial setup; after that, 
>>> the master
>>> pushes to the replica.
>>>
>>> j
>>>
>>> On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote:
>>>> What's wrong with your scenario B: master(s) in internal network, they
>>>> can contact consumers in DMZ and remote rack and replicate to them.
>>>> What do you mean by "to contact for setup" ?
>>>>
>>>> Ludwig
>>>>
>>>> On 08/19/2014 03:12 AM, Joshua J. Kugler wrote:
>>>>> So, we have a need for replication, but the existing push-only 
>>>>> methodology
>>>>> doesn't work for us. I suppose our problems could be attributed to 
>>>>> over-
>>>>> zealous network rules, but it is what it is. :) I'd love to change 
>>>>> our
>>>>> network policy, but we aren't in charge of network policy, and 
>>>>> there is
>>>>> no way I'm swaying the person that is.
>>>>>
>>>>> Topology:
>>>>> 1) DMZ environments 1,...,n
>>>>> 2) An Internal network
>>>>> 3) A remote rack in a data center.
>>>>>
>>>>> Rules (by "talk" I mean initiate connections to):
>>>>> 1) DMZs can talk to each other, somewhat.
>>>>> 2) The Internal network can talk to the DMZs
>>>>> 3) The DMZ *cannot* connect to the Internal network
>>>>> 4) The remote rack of course cannot contact the Internal network, 
>>>>> but can
>>>>> contact the DMZs.
>>>>>
>>>>> Scenario A, Master in a DMZ:
>>>>>    - Slave in the Internal network could contact the DMZ master 
>>>>> for replica
>>>>>
>>>>> setup, but the Master could not contact the slave to push updates
>>>>>
>>>>>    - Slave in the remote rack could contact master in DMZ, but 
>>>>> incoming to
>>>>>
>>>>> remote rack is very restrictive, so it is possible that master 
>>>>> couldn't
>>>>> push.
>>>>>
>>>>> Scenario B: Master in the Internal network.
>>>>>
>>>>>    - Slaves in DMZ and remote rack couldn't contact master for setup,
>>>>>    although
>>>>>
>>>>> the master could contact the slaves to push updates.
>>>>>
>>>>> Scenario C: Master in remote rack
>>>>>
>>>>>    - Not acceptable as remote rack is a testing rack, and may go 
>>>>> down at
>>>>>    any
>>>>>
>>>>> time.
>>>>>
>>>>> So, the best solution, from my current understanding is being able to
>>>>> somehow>
>>>>> do pull-updates for replicas, because then we could have this:
>>>>>    - Master in DMZs
>>>>>    - Slaves in Internal network can contact Master in DMZ for 
>>>>> replica setup
>>>>>    and>
>>>>> updates
>>>>>
>>>>>    - Slaves in remote rack can contact Master in DMZ for replica 
>>>>> setup and
>>>>>
>>>>> updates
>>>>>
>>>>> Any feedback is appreciated, especially if I'm missing 
>>>>> something...obvious
>>>>> or minor.
>>>>>
>>>>> j
>> I think you capture the problem correctly. There is unfortunately no 
>> solution
>> for this at the moment.
>> We considered looking into read only replicas but this is not exactly 
>> what
>> would help here either since changes to RO replicas would be rerouted 
>> to the
>> real masters and thos need to be accessible from DMZ or remote req in 
>> your
>> case - so it will be inbound connection here.
>> I am not sure there is a way to help you here with the current 
>> software. The
>> only option I see is a two different domains - internal and external 
>> with some
>> manually set trust in between. You bight be able to sync people in 
>> some way
>> with some scripts but still that would be quite fragile.
>> Are the users operating inside the FW and in DMZ/remote are really 
>> same users?
>
> Or IPA-to-IPA trust? :-)
>
> Joshua, if you want to experiment:
>
> Ludwig said earlier in this thread that 389 replication will work fine 
> if master is inside internal network (and thus able to contact other 
> replicas in DMZ or external network).
>
> It seems to me that main *technical* problem is "replica setup" phase 
> where replica contacts the original master and not the other way around.
yes, and you make it a read only consumer, otherwise it would try to 
establish a replication connection. So it ends all up in setting this up 
'manually'.
>
> You can use e.g. SSH from master to replica and do some tricks with 
> port forwarding and iptables/routing table so the replica will be able 
> to contact the master inside internal network. (That will breach all 
> policies you have, of course.)
>
> If you want to experiment even more, you can try to use port 
> forwarding for replica setup and then close the hole. 389 replication 
> should work because master will connect to replica and not the other 
> way around. I'm not sure what else will break...
>