Dear tool maintainers!
The domain tools.wikimedia.de, aliasing toolserver.org, has been deprecated for a very long time. It is legacy from the past and we kept it for your convenience so you wouldn't have to modify any tool.
With the toolserver redirects to Tool Labs things are getting complicated enough without this old stuff. If you have very old tools and you are still using tools.wikimedia.de, please get rid of that domain! After the toolserver's shutdown, this redirect will on longer work.
Thanks for your understanding! Cheers, Silke
Silke,
On 9 May 2014 16:37, Silke Meyer silke.meyer@wikimedia.de wrote:
The domain tools.wikimedia.de, aliasing toolserver.org, has been deprecated for a very long time. It is legacy from the past and we kept it for your convenience **so you wouldn't have to modify any tool.**
(emphasis mine)
As tool authors, we typically cannot change the URL people use to access our tool -- if there is a link to tools.wikimedia.de on some wiki, on some website or in someones bookmarks, there is not an easy way to change it.
With the toolserver redirects to Tool Labs things are getting
complicated enough without this old stuff.
What is the problem with just keeping a tools.wikimedia.de/* -> toolserver.org/* redirect? It's a trivial redirect, and users will then automatically be redirected from toolserver.org to their destination.
Merlijn
gudn tach! (Hi!)
On 09.05.2014 16:44, Merlijn van Deen wrote:
What is the problem with just keeping a tools.wikimedia.de/* -> toolserver.org/* redirect? It's a trivial redirect, and users will then automatically be redirected from toolserver.org to their destination.
This is a very legitimate question and I would appreciate a (public) answer to this for the sake of transparency.
Bye seth
Hi!
2014-05-10 22:34 GMT+02:00 seth email_metawiki_138@wg-karlsruhe.de:
gudn tach! (Hi!)
On 09.05.2014 16:44, Merlijn van Deen wrote:
What is the problem with just keeping a tools.wikimedia.de/* -> toolserver.org/* redirect? It's a trivial redirect, and users will then automatically be redirected from toolserver.org to their destination.
This is a very legitimate question and I would appreciate a (public) answer to this for the sake of transparency.
There we go: It is not a trivial redirect: Wikimedia Deutschland will obviously not give the wildcard SSL certificate for *.wikimedia.de to WMF (and WMF would not want to have it). This would mean we would have to completely delegate that subdomain to WMF and guarantee that it stays like that forever. This is hard to guarantee and it is also misleading to delegate a .de subdomain to the Foundation. This is why I'm asking tool developers to replace this link in their tools. (Yes, it is used inside older tools, not just somewhere in this internet.)
Best, Silke
On 11 May 2014 13:55, Silke Meyer silke.meyer@wikimedia.de wrote:
It is not a trivial redirect: Wikimedia Deutschland will obviously not give the wildcard SSL certificate for *.wikimedia.de to WMF (and WMF would not want to have it). This would mean we would have to completely delegate that subdomain to WMF and guarantee that it stays like that forever. This is hard to guarantee and it is also misleading to delegate a .de subdomain to the Foundation.
First of all: Why would the (sub)domain need to be delegated to the WMF? The redirect could just be on WMDE servers.
If the redirect *has* to be on Foundation servers for some reason, it could just use a specific tools.wikimedia.de certificat -- or we could just kill SSL altogether -- the tools.wikimedia.de domain is from before the toolserver even had SSL support.
In numbers: there are only 11 links to https://tools.wikimedia.de on enwiki, as compared to 87059 to http://tools.wikimedia.de. Even on dewiki, which should be the more privacy-interested people ;-), the numbers are 13 (https) vs 14673 (http).
This is why I'm asking tool developers to replace this link in their tools. (Yes, it is used inside older tools, not just somewhere in this internet.)
In that case, I suggest to e-mail those tool authors directly to ask them to fix that.
Merlijn
Merlijn van Deen wrote:
On 11 May 2014 13:55, Silke Meyer <silke.meyer@wikimedia.de mailto:silke.meyer@wikimedia.de> wrote:
It is not a trivial redirect: Wikimedia Deutschland will obviously not give the wildcard SSL certificate for *.wikimedia.de <http://wikimedia.de> to WMF (and WMF would not want to have it). This would mean we would have to completely delegate that subdomain to WMF and guarantee that it stays like that forever. This is hard to guarantee and it is also misleading to delegate a .de subdomain to the Foundation.First of all: Why would the (sub)domain need to be delegated to the WMF? The redirect could just be on WMDE servers.
If the redirect *has* to be on Foundation servers for some reason, it could just use a specific tools.wikimedia.de http://tools.wikimedia.de certificat -- or we could just kill SSL altogether -- the tools.wikimedia.de http://tools.wikimedia.de domain is from before the toolserver even had SSL support.
+1
I think you are viewing things more complex than they really are, Silke.
On 11 May 2014, at 20:03, Platonides platonides@gmail.com wrote:
Merlijn van Deen wrote:
On 11 May 2014 13:55, Silke Meyer <silke.meyer@wikimedia.de mailto:silke.meyer@wikimedia.de> wrote:
It is not a trivial redirect: Wikimedia Deutschland will obviously not give the wildcard SSL certificate for *.wikimedia.de http://wikimedia.de to WMF (and WMF would not want to have it). This would mean we would have to completely delegate that subdomain to WMF and guarantee that it stays like that forever. This is hard to guarantee and it is also misleading to delegate a .de subdomain to the Foundation.
First of all: Why would the (sub)domain need to be delegated to the WMF? The redirect could just be on WMDE servers.
If the redirect *has* to be on Foundation servers for some reason, it could just use a specific tools.wikimedia.de http://tools.wikimedia.de certificat -- or we could just kill SSL altogether -- the tools.wikimedia.de http://tools.wikimedia.de domain is from before the toolserver even had SSL support.
+1
I think you are viewing things more complex than they really are, Silke.
Indeed. Assuming WMDE isn't planning on not having any web servers, their existing web server for wikimedia.de can keep redirecting tools.wikimedia.de to toolserver.org. No changes necessary.
If WMDE really wants to remove them, they could point that subdomain to WMF servers and have WMF do the redirect and simply don't provide an SSL certificate. E.g. WMF would use a self-signed certificate or an invalid one like the one for wikipedia.org, WMF does this all the time for old or unused domains:
wikipedia.com * https://www.wikipedia.com/
wikimediacommons.org * https://wikimediacommons.org/
And if we really really want, one could purchase a separate certificate for just tools.wikimedia.org (so that the wildcard one isn't needed) and transfer only that to WMF.
— Krinkle
Hi again,
Indeed. Assuming WMDE isn't planning on not having any web servers, their existing web server for wikimedia.de can keep redirecting tools.wikimedia.de to toolserver.org. No changes necessary.
So okay, not making any change to the DNS entry is completely okay for me. WMF ops then have to decide about the SSL certificate question.
If WMDE really wants to remove them, they could point that subdomain to WMF servers and have WMF do the redirect and simply don't provide an SSL certificate. E.g. WMF would use a self-signed certificate or an invalid one like the one for wikipedia.org, WMF does this all the time for old or unused domains:
wikipedia.com
wikimediacommons.org
And if we really really want, one could purchase a separate certificate for just tools.wikimedia.org (so that the wildcard one isn't needed) and transfer only that to WMF.
For me, it is important that I don't have to deal with that domain any longer. Simply keeping the CNAME causes on work at all. If you at WMF want to handle the certificate question in the future, you can go ahead. At the Hackathon, I understood that Coren is no fan of such a solution though.
Best, Silke
Hi all,
On 20/05/14 13:27, Silke Meyer wrote:
Hi again,
Indeed. Assuming WMDE isn't planning on not having any web servers, their existing web server for wikimedia.de can keep redirecting tools.wikimedia.de to toolserver.org. No changes necessary.
So okay, not making any change to the DNS entry is completely okay for me. WMF ops then have to decide about the SSL certificate question.
keeping the domain a CNAME just as is and considering it a deprecated one at the WMF end makes the most sense to me. This way it is just a legacy entry on WMDE side that never has to be touched again except for eventual deletion. And on WMF side it will receive an invalid certificate. So tools will not fail, but give a cert warning which should hopefully trigger fixing URLs at the maintainers' at some point in time. Also this solution does not need any special coordination of certificates, A or MX-records and whatnot.
2cents amette
If WMDE really wants to remove them, they could point that subdomain to WMF servers and have WMF do the redirect and simply don't provide an SSL certificate. E.g. WMF would use a self-signed certificate or an invalid one like the one for wikipedia.org, WMF does this all the time for old or unused domains:
wikipedia.com
wikimediacommons.org
And if we really really want, one could purchase a separate certificate for just tools.wikimedia.org (so that the wildcard one isn't needed) and transfer only that to WMF.
For me, it is important that I don't have to deal with that domain any longer. Simply keeping the CNAME causes on work at all. If you at WMF want to handle the certificate question in the future, you can go ahead. At the Hackathon, I understood that Coren is no fan of such a solution though.
Best, Silke
Silke Meyer silke.meyer@wikimedia.de wrote:
[...]
For me, it is important that I don't have to deal with that domain any longer. Simply keeping the CNAME causes on work at all. If you at WMF want to handle the certificate question in the future, you can go ahead. At the Hackathon, I understood that Coren is no fan of such a solution though.
I think Merlijn and Platonides are just proposing to replace the CNAME with a virtual host tools.wikimedia.de on the web- server that currently handles wikimedia.de, blog.wikimedia.de, forum.wikimedia.de and www.wikimedia.de that just does a HTTP redirect to toolserver.org (which then gets handled by WMF), and that should be *very* close to "no work at all" :-).
But there would only be a difference in HTTPS compared to the CNAME solution, and as Merlijn pointed out that tools.wikimedia.de predates HTTPS on Toolserver, I'm fine with keeping the CNAME (or pointing it to the new webserver) as well.
Tim
Silke Meyer wrote:
The domain tools.wikimedia.de, aliasing toolserver.org, has been deprecated for a very long time. It is legacy from the past and we kept it for your convenience so you wouldn't have to modify any tool.
With the toolserver redirects to Tool Labs things are getting complicated enough without this old stuff. If you have very old tools and you are still using tools.wikimedia.de, please get rid of that domain! After the toolserver's shutdown, this redirect will on longer work.
Thanks for your understanding!
I don't really understand. Wikimedia Deutschland is clearly going to continue owning and operating wikimedia.de. The cost of the redirects is likely dramatically outweighed by the benefit to not breaking so many links.
For what it's worth:
MariaDB [enwiki_p]> select count(*) from externallinks where el_index like 'http://de.wikimedia.tools./%'; +----------+ | count(*) | +----------+ | 87059 | +----------+ 1 row in set (1.04 sec)
Another 14,674 results on dewiki_p. We're probably talking about half a million links on the Web... I think it's worth a few additional lines of Web server configuration to keep these links functional, if possible.
I suppose it could be argued that having a domain under *.wikimedia.de could be dangerous, but... eh. This doesn't seem to be what's being said in this e-mail, in any case.
MZMcBride
toolserver-l@lists.wikimedia.org