Closed
Bug 763389
Opened 12 years ago
Closed 12 years ago
cal-vm-win32-1 needs flows setup to connect to calendar-master
Categories
(Infrastructure & Operations Graveyard :: NetOps: DC ACL Request, task, P1)
Infrastructure & Operations Graveyard
NetOps: DC ACL Request
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: Callek, Assigned: ravi)
References
Details
So, Fallen and the calendar team has been missing windows builds for a few weeks now, so this is a high priority. the newly setup cal-vm-win32-1[.community.scl3.mozilla.com] needs to be able to connect to its buildbot master calendar-master[.mozillalabs.com] calendar-master.mozillalabs.com resolves to calendar-master.mozillamessaging.com as well (as an FYI) calendar-master seems to respond to port 80 for buildbot (as a route to internal-to-machine port 9030 afaict) So given my base assumptions (CC: gozer to help confirm) we need the following for Calendar to be able to work with this VM: ------------------------------ cal vm slave -> cal master: 63.245.223.105 -> 63.245.223.165:tcp/9010 cal vm slaves -> symbolpush 63.245.223.105 -> 63.245.216.248:tcp/22 ------------------------------ (Additionally Someone should verify that stage.mozilla.org, hg, and cvs, are all already openly accessible from this host)
Reporter | ||
Comment 1•12 years ago
|
||
(In reply to Justin Wood (:Callek) from comment #0) > ------------------------------ > cal vm slave -> cal master: > 63.245.223.105 -> 63.245.223.165:tcp/9010 Err Copy/Paste error, should be tcp/80 (afaict)
Comment 2•12 years ago
|
||
(In reply to Justin Wood (:Callek) from comment #0) > So, Fallen and the calendar team has been missing windows builds for a few > weeks now, so this is a high priority. > > the newly setup cal-vm-win32-1[.community.scl3.mozilla.com] needs to be able > to connect to its buildbot master calendar-master[.mozillalabs.com] > > calendar-master.mozillalabs.com resolves to > calendar-master.mozillamessaging.com as well (as an FYI) > > calendar-master seems to respond to port 80 for buildbot (as a route to > internal-to-machine port 9030 afaict) Yes, that was a workaround for something that didn't let non port-80 outbound connections at some point. The internal machine name is momo-cal-master-01.vm.labs.scl3.mozilla.com (10.22.112.142) > So given my base assumptions (CC: gozer to help confirm) we need the > following for Calendar to be able to work with this VM: > > ------------------------------ > cal vm slave -> cal master: > 63.245.223.105 -> 63.245.223.165:tcp/9010 If going out via the external IP of the calendar master, that would have to be tcp/80, to keep things the way they are. If instead, going into the private IP of the calendar master, that would be 63.245.223.105 -> 10.22.112.142:tcp/9010 But I don't know if that's even possible.
Reporter | ||
Comment 3•12 years ago
|
||
(In reply to Philippe M. Chiasson (:gozer) from comment #2) > If going out via the external IP of the calendar master, that would have to > be tcp/80, to keep things the way they are. > > If instead, going into the private IP of the calendar master, that would be > 63.245.223.105 -> 10.22.112.142:tcp/9010 Just to be *clear* if this is useable with non-port-80, we want port *9030* not *9010* And "to ravi:" port 9030 serves the same function as port 9010 does for SeaMonkey [incase internal used-port docs need updating]
Comment 4•12 years ago
|
||
knocking down to severity:P1 normal. Netops will catch this on the daily triage cycle if not sooner.
Severity: major → normal
Priority: -- → P1
Assignee | ||
Comment 5•12 years ago
|
||
63.245.223.105 -> 63.245.223.165 80/tcp has been open per comment 2 and to expedite things without having to trigger an Opsec review/approval. I'll keep this open for verification this works.
Assignee: network-operations → ravi
Status: NEW → ASSIGNED
Component: Server Operations: Netops → Server Operations: ACL Request
Comment 6•12 years ago
|
||
C:\Documents and Settings\cltbld>telnet 63.245.223.165 80 Connecting To 63.245.223.165...Could not open connection to the host, on port 80: Connect failed
Assignee | ||
Comment 7•12 years ago
|
||
Der. User (me) error. I can't test from your machine, but I opened the flow from jump1.community which is on the same network and part of the same policy and it worked. [root@jump1.community.scl3 ~]# nc -vz 63.245.223.165 80 Connection to 63.245.223.165 80 port [tcp/http] succeeded!
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 8•12 years ago
|
||
Unfortunately still doesn't work for me from the VM. If you want to try it out directly on the machine, try the passwords on file for cg-xserve03. User administrator and cltbld.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 9•12 years ago
|
||
Ravi, any updates on this?
Assignee | ||
Comment 10•12 years ago
|
||
I was traveling from Boston back to SF yesterday so was unavailable from 1830 EDT to today. Your netmask is incorrectly configured on the host. It and all hosts on this network should be 255.255.255.128 (/25). Connection-specific DNS Suffix . : Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter Physical Address. . . . . . . . . : 00-50-56-BB-65-53 DHCP Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 63.245.223.105 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 63.245.223.1 DNS Servers . . . . . . . . . . . : 4.2.2.1 8.8.8.8
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Infrastructure & Operations
Updated•2 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•