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

-- 
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: pedah...@gmail.com
PGP Key: http://pgp.mit.edu/  ID 0x73B13B6A

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to