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" ?
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.
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
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
- Slaves in remote rack can contact Master in DMZ for replica setup and
Any feedback is appreciated, especially if I'm missing something...obvious or
Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project