+++ This bug was initially created as a clone of Bug #964486 +++ Can we please set up a new DNS name and IP address for hg.m.o? We need to divert some traffic out of our VPN tunnel to the public internet. We'd like to move SSL traffic to/from hg outside the VPN, but that requires us to have a different IP to adjust the routing tables. Let's use 'hg-ssl.m.o' as the name.

i just mentioned this to :laura, we're going to have to be *extremely* careful with this request. i have sought advise from the source control experts here, but my initial concerns are the following: 1. ssl certificate change on hg to accommodate the hg-ssl subject alternative name - will this impact current development? 2.server aliases - so that we dont have to send customer host headers or the like, we'll need to add a server alias of hg-ssl. this is straight forward in apache, but can it be done gracefully in mercurial? i will be having a pow-wow later this afternoon with our source control folks to get their take on this change and report back with my findings.

The bulk of our traffic is for hg-internal.dmz.scl3.mozilla.com, which is internal only AIUI. We'd need a public IP and name for this.

(In reply to Chris AtLee [:catlee] from comment #2) > The bulk of our traffic is for hg-internal.dmz.scl3.mozilla.com, which is > internal only AIUI. We'd need a public IP and name for this. this adds another layer of complexity here. hg-internal.dmz.scl3 is served on an internal only zeus cluster. on this internal (only) cluster we cannot add an external ip. without a major overhaul, that would likely require downtime, we cannot get this done.

Actualy. The hg-internal has a pool that is made from 10.22.74.37 10.22.74.38 10.22.74.39 The servers are in the DMZ Vlan and subnet and accessible from the generic ZLB "external" cluster. They are actually configured as a part of the larger pool behind the hg.m.o VIP 10.22.74.33 10.22.74.34 10.22.74.35 10.22.74.36 10.22.74.37 10.22.74.38 10.22.74.39 TL;DR nothing prevents us from creating a new virtual server, VIP and using just the three servers we need as a backend.

(In reply to Michal Purzynski [:michal`] (use NEEDINFO) from comment #4) > Actualy. > > The hg-internal has a pool that is made from > > 10.22.74.37 > 10.22.74.38 > 10.22.74.39 > > The servers are in the DMZ Vlan and subnet and accessible from the generic > ZLB "external" cluster. They are actually configured as a part of the larger > pool behind the hg.m.o VIP > > 10.22.74.33 > 10.22.74.34 > 10.22.74.35 > 10.22.74.36 > 10.22.74.37 > 10.22.74.38 > 10.22.74.39 > > TL;DR nothing prevents us from creating a new virtual server, VIP and using > just the three servers we need as a backend. i didn't know this! thnx :michal`. let me review this further.

so after much discussion and discovery (i am new to our hg setup), i found that there are no differences between the hg-internal and the hg pool nodes. additionally, ssl is enforced on hg.mozilla.org, which solves this very bug. all you should need to do is switch from using hg-internal.dmz.scl3.mozilla.com to hg.mozilla.org. let me know how this works out (or if i missed something obvious).

Status? I believe for other reasons, we decided not to pursue the alternate IP address plan. Can we resolve this WONTFIX?

:lauara - i will defer this to you. i'm not currently up to speed on the current status of this.

we decided in meeting okay to not pursue at this time.