Re: [Freeipa-users] Need for some pull-style replication, or an alternate solution
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... -- 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
Re: [Freeipa-users] Need for some pull-style replication, or an alternate solution
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. 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... -- Petr^2 Spacek -- 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
Re: [Freeipa-users] Need for some pull-style replication, or an alternate solution
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? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Need for some pull-style replication, or an alternate solution
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
Re: [Freeipa-users] Need for some pull-style replication, or an alternate solution
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 -- 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
[Freeipa-users] Need for some pull-style replication, or an alternate solution
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
