Page MenuHomePhabricator

Set up "w.wiki" domain for usage with UrlShortener
Closed, ResolvedPublic

Description

Splitting discussing the "w.wiki" domain into a separate bug per:

The "w.wiki" part of this plan probably needs some confirmation and discussion, separately from the rest of this, re TLS-related details and purchasing additional certificate SANs, etc.

Event Timeline

Legoktm created this task.Aug 10 2015, 11:51 PM
Legoktm raised the priority of this task from to Normal.
Legoktm updated the task description. (Show Details)
Restricted Application added a subscriber: Matanya. · View Herald TranscriptAug 10 2015, 11:51 PM
Krenair set Security to None.
Krenair added a subscriber: Krenair.
Jorm removed a subscriber: Jorm.Aug 11 2015, 12:20 AM

Probably the most important question (since I haven't really looked at UrlShortener) is: are there subdomains involved, or just https://w.wiki/... ?

Either way, we're going to need to fix the w.wiki zonefile (it's currently a symlink to wikipedia.org, which isn't right), and we'll need to add TLS support for it. We could take two possible routes with that:

  1. We could add another SAN onto our unified list for w.wiki
  2. We could simply get a new non-wildcard cert for w.wiki and deploy it separately alongside the unified on the text clusters

Or, I guess we could do (2) for now and deal with rolling it up into (1) the next time we naturally renew the unified.

Probably the most important question (since I haven't really looked at UrlShortener) is: are there subdomains involved, or just https://w.wiki/... ?

No subdomains. Just https://w.wiki/{shortcode}. This will be an internal rewrite to meta.wikimedia.org/w/index.php?title=Special:UrlRedirector/{shortcode} (or any other wiki), which will either output a 301 or an error page.

Either way, we're going to need to fix the w.wiki zonefile (it's currently a symlink to wikipedia.org, which isn't right), and we'll need to add TLS support for it. We could take two possible routes with that:

  1. We could add another SAN onto our unified list for w.wiki
  2. We could simply get a new non-wildcard cert for w.wiki and deploy it separately alongside the unified on the text clusters

Or, I guess we could do (2) for now and deal with rolling it up into (1) the next time we naturally renew the unified.

SAN = https://en.wikipedia.org/wiki/SubjectAltName ? I don't understand the details and implications here, so I'll leave it up to you to decide which is best :)

ori added a subscriber: ori.Aug 11 2015, 9:42 PM
  1. We could add another SAN onto our unified list for w.wiki
  2. We could simply get a new non-wildcard cert for w.wiki and deploy it separately alongside the unified on the text clusters

Or, I guess we could do (2) for now and deal with rolling it up into (1) the next time we naturally renew the unified.

I think (2) would be fine, at least from the angle of performance, which I don't think is critical here.

SAN = https://en.wikipedia.org/wiki/SubjectAltName ? I don't understand the details and implications here, so I'll leave it up to you to decide which is best :)

Yeah. One downside of taking the "easy at the moment" way out with a separate cert is that https://w.wiki/ would only work for SNI-capable clients. That excludes IE[78]-on-XP (but not IE8 on Win7+), Android 2.x, and probably a long tail of older/feature phones and strange devices like older "Smart TV"s and such (some of the oldest/crappiest of that long tail already don't work with us in general, but the list grows quite a bit for a domain which requires SNI, which our primary domains do not).

We've been OK with requiring SNI support for misc-web services (e.g. phabricator, monitoring) before, but we've never required it on our "primary" domains on the text/upload/mobile endpoints before. This falls into the primary category I think, so maybe we're better off looking into adding the SAN and re-issuing the primary unified certs. I don't think we've done that process before, at least not via GlobalSign, and it may involve some custom support from our rep there. We have some other unrelated things to sort out with these certs in the near future anyways, now may be as good a time as any to get the ball rolling. I'll start looking into how feasible that is tomorrow.

In the interest of full disclosure of options, there's a middle-ground option where we get a simple separate cert for w.wiki, and also give it its own separate IP address from the others, and then it works for non-SNI clients as well. Our standard nginx->varnish terminator stuff isn't set up to handle multiple distinct server-IPs per cluster in this manner at this time, but it could be refactored a bit to handle it.

Dzahn added a subscriber: Dzahn.Aug 12 2015, 2:59 AM
Legoktm changed the task status from Open to Stalled.Sep 22 2015, 1:04 AM

I spoke with @BBlack on IRC, when we renew the unified cert in mid-October, we will also add w.wiki to it. Marking as stalled since we're just waiting for now.

revi added a subscriber: revi.Oct 11 2015, 2:48 PM

Also where should we do the redirect? I guess any requests to w.wiki/(.*) should redirect to meta.wikimedia.org/w/index.php?title=Special:UrlShortener/$1 on the appservers. Should we just do this on varnish?

Err, by redirect I mean 'route to' from varnish, not an actual redirect.

Definitely not varnish!

RobH added a subscriber: RobH.Oct 22 2015, 8:59 PM

Addiing another domain adds to the overall cost of the certificate, and thus would need additional budget approval.

Also, T101048 involves discussion on how to handle all the non top level domains we own and how to support them.

RobH added a subtask: Unknown Object (Task).Oct 29 2015, 5:11 PM
BBlack closed subtask Unknown Object (Task) as Resolved.Dec 11 2015, 2:15 AM

Change 258406 had a related patch set uploaded (by BBlack):
add w.wiki to VCL TLS redirect/HSTS

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

Change 258407 had a related patch set uploaded (by BBlack):
w.wiki: unlink from wp.o, remove all hostnames within (unused)

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

Change 258407 merged by BBlack:
w.wiki: unlink from wp.o, remove all hostnames within (unused)

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

Change 258406 merged by BBlack:
add w.wiki to VCL TLS redirect/HSTS

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

Legoktm changed the task status from Stalled to Open.Dec 11 2015, 2:40 AM

No longer stalled!

jrbs added a subscriber: jrbs.Dec 11 2015, 2:42 AM
BBlack closed this task as Resolved.Dec 11 2015, 2:42 AM
BBlack claimed this task.

The domain/Traffic part is resolved here. The rest is up to apache/MW config and code (currently https://w.wiki/ just redirects to https://www.wikipedia.org/

BBlack moved this task from Triage to Done on the Traffic board.Dec 11 2015, 4:24 PM
RobH reopened subtask Unknown Object (Task) as Open.Dec 16 2015, 4:57 PM
RobH closed subtask Unknown Object (Task) as Resolved.May 3 2016, 5:29 PM
Nirmos added a subscriber: Nirmos.Apr 16 2019, 7:17 PM