Closed Bug 740756 Opened 14 years ago Closed 14 years ago

unable to reach pulse.mozilla.org from releng-dashboard-sandbox

Categories

(Infrastructure & Operations Graveyard :: NetOps, task)

Product:
Infrastructure & Operations Graveyard
Component:
NetOps
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bear, Assigned: cransom)

Details

(Whiteboard: [briarpatch])

I shut down some of the briar-patch daemons to upgrade them and on restart the Pulse daemon could not reconnect. releng-dashboard-sandbox1.vm1.labs.sjc1.mozilla.com telnet pulse.mozilla.org 5672 Trying 63.245.216.240... telnet: connect to address 63.245.216.240: Connection timed out on another server (my home connection) that works this is preventing the briar-patch data gathering daemons from running
reducing to major - would love to get this fixed but it is not a "drop everything" event now (I'm using port forwarding to work around it)
Severity: critical → major
Assignee: server-ops-releng → dustin
Smells like the same problem as before with the core firewall in MPT. Some NAT rules need kicking.
yea, it's definitely a rule change as I realize now the daemon was running all pig-in-mud happy for the last week and pulling in pulse messages. It's only when I stop/start'd it did this happen.
I *think* that means this is fine? It's almost a month later, so I hope so :)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
this flow has been broken (briarpatch)[mtaylor@releng-dashboard-sandbox1 briar-patch]$ telnet pulse.mozilla.org 5672 Trying 63.245.216.240... (briarpatch)[mtaylor@releng-dashboard-sandbox1 briar-patch]$ ping pulse.mozilla.org PING pulse.mozilla.org (63.245.216.240) 56(84) bytes of data. ^C --- pulse.mozilla.org ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4152ms
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [briarpatch]
The fwsm bailed out over the weekend again :( Netops, is my guess right?
Oops, actually reassigned this time .. netops, is this a fwsm problem?
Assignee: dustin → network-operations
Component: Server Operations: RelEng → Server Operations: Netops
QA Contact: arich → ravi
Assignee: network-operations → cransom
we are trying to hunt down why these happen though I've run the fix to clear this up. can you confirm?
it is working
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.