Page MenuHomePhabricator

Proxy corner case: proxy name foo.wmflabs.org == domain name foo.wmflabs.org
Closed, ResolvedPublic

Description

The example of this I'm looking at right now is 'tiles.wmflabs.org'. I've set up a by-hand entry right now, but perhaps the proxy panel should handle it.

Ordinarily a record like 'foo.wmflabs.org' would be on the domain 'wmflabs.org'. In the case of tiles.wmflabs.org, though, the domain 'tiles.wmflabs.org' also exists. In that case, apparently the record 'tiles.wmflabs.org' needs to belong to the subdomain 'tiles.wmflabs.org' -- if it belongs to wmflabs.org it doesn't resolve.

So, I guess this is yet another special case that the proxy panel needs to handle :(

Event Timeline

For the record, I'm not sure that fixing this is a better solution than just saying "Don't do that then"

For the record, I'm not sure that fixing this is a better solution than just saying "Don't do that then"

Would this mean that we can no longer have https protection for Horizon proxied services? It looks like the CN on our cert is only *.wmflabs.org

Would this mean that we can no longer have https protection for Horizon proxied services?

I was thinking more in terms of the opposite case: 'If you want a proxy at projectname.wmflabs.org, then you can't also have things in a subdomain like foo.projectname.wmflabs.org"

I've just verified that there are no longer any current proxies bitten by this issue. It's still a UI issue though.

chasemp triaged this task as Medium priority.Apr 4 2016, 1:51 PM

well, I was wrong about the 'no longer any current proxies bitten' thing -- wma.wmflabs.org is one. So my audit was wrong somehow.

For the record, I'm not sure that fixing this is a better solution than just saying "Don't do that then"

Would this mean that we can no longer have https protection for Horizon proxied services? It looks like the CN on our cert is only *.wmflabs.org

If we really wanted to support *.*.wmflabs.org domains I imagine we could have some setup involving Let's Encrypt to deal with that.
*.wmflabs.org domains are fine.

Change 471203 had a related patch set uploaded (by Alex Monk; owner: Alex Monk):
[openstack/horizon/wmf-proxy-dashboard@master] Handle proxy domain existing as an actual zone in the current project

https://gerrit.wikimedia.org/r/471203

Change 471203 merged by Andrew Bogott:
[openstack/horizon/wmf-proxy-dashboard@master] Handle proxy domain existing as an actual zone in the current project

https://gerrit.wikimedia.org/r/471203

Change 479565 had a related patch set uploaded (by Andrew Bogott; owner: Alex Monk):
[openstack/horizon/wmf-proxy-dashboard@ocata] Handle proxy domain existing as an actual zone in the current project

https://gerrit.wikimedia.org/r/479565

Change 479565 merged by Andrew Bogott:
[openstack/horizon/wmf-proxy-dashboard@ocata] Handle proxy domain existing as an actual zone in the current project

https://gerrit.wikimedia.org/r/479565

Change 479566 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[openstack/horizon/deploy@ocata] Update wmf-proxy-dashboard

https://gerrit.wikimedia.org/r/479566

Change 479566 merged by Andrew Bogott:
[openstack/horizon/deploy@ocata] Update wmf-proxy-dashboard

https://gerrit.wikimedia.org/r/479566

Mentioned in SAL (#wikimedia-operations) [2018-12-13T23:13:51Z] <andrew@deploy1001> Started deploy [horizon/deploy@18c4ca6]: Rolling out fix for T131367

Mentioned in SAL (#wikimedia-operations) [2018-12-13T23:17:16Z] <andrew@deploy1001> Finished deploy [horizon/deploy@18c4ca6]: Rolling out fix for T131367 (duration: 03m 25s)

Andrew claimed this task.

I've deployed @Krenair 's fix for this and it looks good.