Closed Bug 673973 Opened 13 years ago Closed 13 years ago

DNS: diresworb.org point to browserid-stage1.vm1.labs.sjc1.mozilla.com

Categories

(Infrastructure & Operations Graveyard :: NetOps, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lloyd, Assigned: arzhel)

References

Details

this can be taken live/made publicly visible immediately.
changed from beta.browserid.org to diresworb.org to keep beta code off a subdomain of production.
Summary: DNS: beta.browserid.org point to browserid-stage1.vm1.labs.sjc1.mozilla.com → DNS: diresworb.org point to browserid-stage1.vm1.labs.sjc1.mozilla.com
confidential because ticket contains a domain name not yet registered.  kinda paranoid, whatever.
Group: mozilla-corporation-confidential
Group: mozilla-corporation-confidential
So, this is live, but not resolving from everywhere it should. Moving over to netops to sort out why this is the case.

Resolves from the internet, not from 10.2.10.5.

My changes were svn r18223, but the slave config scripts didn't do anything, so I think that's missing.
Assignee: server-ops-labs → network-operations
Component: Server Operations: Labs → Server Operations: Netops
QA Contact: zandr → mrz
From where I sit it resolves fine:

[lth@lloydpro browserid]$ dig diresworb.org | egrep ^diresworb
diresworb.org.		300	IN	A	63.245.211.58

but the load balancer doesn't seem to want to talk to me.

[lth@lloydpro browserid]$ curl https://63.245.211.58
curl: (7) couldn't connect to host

FWIW, 
lloyd
bump.

Hi!  Any chance we could get a little love for this bug?  It's making some people that I would prefer to be happy, sad.

Thank you, and sorry to nag,
lloyd
The first problem is a DNS misconfiguration/bug that is now fixed.

For the second, my curl says everything is good, from both my work computer and and my personal server.
Could you please check again, maybe also with a wget --no-check-certificate https://diresworb.org/
a traceroute to that IP and/or a telnet 63.245.211.58 443 for example.

Thanks!
Assignee: network-operations → arzhel
This is what I see:
$ curl https://63.245.211.58
curl: (51) SSL: certificate subject name '*.diresworb.org' does not match target host name '63.245.211.58'

From my Mac w/ and w/o VPN-MPT

This
$ wget --no-check-certificate https://diresworb.org/
gets me this (still using VPN MPT):
--2011-08-05 16:16:04--  https://diresworb.org/
Resolving diresworb.org... 63.245.211.58
Connecting to diresworb.org|63.245.211.58|:443... connected.
WARNING: certificate common name `*.diresworb.org' doesn't match requested host name `diresworb.org'.
HTTP request sent, awaiting response... 200 OK
Length: 1991 (1.9K) [text/html]
Saving to: `index.html'

100%[==================================================================================================>] 1,991       --.-K/s   in 0s      

2011-08-05 16:16:04 (22.7 MB/s) - `index.html' saved [1991/1991]
(In reply to James Bonacci [:jbonacci] from comment #8)

> WARNING: certificate common name `*.diresworb.org' doesn't match requested
> host name `diresworb.org'.

True, but unimportant. diresworb.org is in the SubjAltName of the cert. Why wget doesn't look at this is beyond me.
Is there still something wrong here, or can I close the bug?
As far as I can tell, everything is working as it should. I can access Beta from within Mozilla and outside Mozilla. Please close.
per comment 11
Status: NEW → RESOLVED
Closed: 13 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.