If I understood http://permalink.gmane.org/gmane.org.wikimedia.labs.announce/49 correctly, the Maps project is shut down until the NFS recovery is complete. So if a.toolserver.org & Co. are served by the Maps project, this task is effectively blocked by that circumstance.

Note tht reinstating these domains have ceased making sense after all wikis were made HTTPS-only. As a result of that, a single subdomain would work faster - not only because TLS handshakes make multiple domains slower but also because SPDY/HTTP 2.0 make multiple requests to the same domain actually faster over HTTPS. So, instead of bringing the subdomains back, links to them should be eliminated instead.

In T103272#1386107, @scfc wrote:

If I understood http://permalink.gmane.org/gmane.org.wikimedia.labs.announce/49 correctly, the Maps project is shut down until the NFS recovery is complete. So if a.toolserver.org & Co. are served by the Maps project, this task is effectively blocked by that circumstance.

Can't we use the OSM tile servers as a temporary replacement? I remember some Wikimania talk in Gdansk about Wikimedia sites bringing too much traffic to those servers, but OSM has already upgraded their hardware several times in the last few years.

AFAIUI, http://wiki.openstreetmap.org/wiki/Tile_usage_policy explicitly prohibits switching to OSM tile servers without their prior approval. And http://donate.openstreetmap.org/server2015/ says:

It's upgrade time! OpenStreetMap is growing, servers are projected to hit capacity by mid 2015. […]

so the timing is bad :-).

Is there an ETA for the Maps project coming back online? This week?

(Assuming that the WMF tile server indeed is part of the Maps project.)

I switch the standard tiles to osm.org:
https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=de&uselang=de&title=Pirna&zoom=11&lat=50.96033&lon=13.94839

With only 100 Tile request/s we will be no problem for OSM. They have more datacenter than Wikimedia:
http://dns.openstreetmap.org/tile.openstreetmap.org.html

I switch the standard tiles to osm.org

Does this mean that all the services relying on //tiles.wmflabs.org/osm/ such as the MapSources extension (T103073) will start working again after the switch was done? If yes this will be great!

No I change only the scripts we have in production inside Wikipedia and Commons.
This doesn't also help maps that base on hikebikemap-tiles or blackwhite-map.

This is causing SSL certificate warnings on production wikis at three levels:

https://nl.wikipedia.org/wiki/Amsterdam
-> "Kaart" (Map)

The widget makes requests to a.toolserver.org using protocol-relative urls (which expands to HTTPS now).

GET https://b.toolserver.org/tiles/osm-no-labels/12/2103/1346.png
net::ERR_INSECURE_RESPONSE

1. This is responded to with the wrong certificate. toolserver.org instead of *.toolserver.org.

2. It then redirects to insecure HTTP:

http://a.tiles.wmflabs.org/osm-no-labels/12/2103/1346.png

3. The HTTPS variant of this uses an invalid certificate (*.wmflabs.org does not cover *.tiles.wmflabs.org). Presumably this should use something like tiles-a.wmflabs.org.

https://a.tiles.wmflabs.org/osm-no-labels/12/2103/1346.png
NET::ERR_CERT_COMMON_NAME_INVALID

tiles.wmflabs.org
*.toolserver.org

Doesn't seem to work anymore. No tiles are provided.

https://tools.wmflabs.org/geohack/geohack.php?pagename=Berlin&language=de&params=52.518611111111_N_13.408333333333_E_region:DE-BE_type:city(3469849)

Affirmative. The tiles are gone, e.g. on WikiVoyage.

Would it make sense to switch dewiki to the new maps server, just like it-wiki, ru-wiki, en-wikivoyage and ru-wikivoyage did? Italian Wiki switch documented here (example). Russian wiki geohack looks like this, and their changes documented here.
P.S. I am not exactly sure who is maintaining the *.tiles.wmflabs.org.

Would it make sense to switch dewiki

Perhaps it would. But what about all the other wikis out there not run by WMF?

In T103272#1895499, @Kghbln wrote:

Perhaps it would. But what about all the other wikis out there not run by WMF?

I think we should enable access to the WMF maps tiles to the world as soon as we get more production servers in place, but we should have a separate discussion about that. @BBlack is looking at that.

IMHO all maps should use the new maps server. Personally I'm more interested in the in-article-pop-up-thingy (i. e. the frame for example for https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=ru&uselang=ru&params=55_45_21_N_37_37_4_E_type:city_scale:100000&title=%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0) as it is very useful to get an immediate feeling for where the subject of an article is located.

@scfc - I'm working on that as part of the Kartographer extension. See demo here. (it can be made into a popup fairly easily later)

There are services other than Wikis that are using some of these tiles (I can only speak for the hikebike and hillshading tiles), like KDE Marble, and web pages like http://gpsies.com - they were in contact with previous admins and got told it wouldn't be a problem to deliver these tiles through them. Actually, there was even extra work done to accommodate these services during the switchover to wmflabs.
While this probably wasn't a proper service level agreement, I'm kinda surprised to see the toolserver replacement tiles.wmflabs.org go so soon.

I'm kinda surprised to see the toolserver replacement tiles.wmflabs.org go so soon.

This implies that there were plans form the start to cease this service. I there any spot were somebody not following this topic on a daily basis can read about this. Was there some kind of announcement. I feel like having had a migration time without being told about it. In June the status was that this service will be move to wmflabs.org and that's it. This seems to be a very desagrable situation. I am pretty saddened to tell the truth.

I don't think this was intentional--at least I haven't heard of these boxes being scheduled to go down. I would think it's a bug somewhere, and simply needs someone who knows about this service to look at it.

I attempted to log into the main instance for this, but it just timed out. Are any maintainers able to log in?

NB: strictly speaking, WMF Labs run on donated money, so third parties shouldn't make any demands as whatever traffic/hardware they're utilizing is paid for with money donated for the upkeep of Wikimedia projects.

I 've rebooted the instance that serves those tiles, seems like it suffered a partial freeze due to an NFS outage earlier this week which cause the instance to be mostly unresponsive (could not login via ssh, obviously HTTP requests would not work etc). Seems like it is serving tiles fine again. Tested with https://tools.wmflabs.org/geohack/geohack.php?pagename=Berlin&language=de&params=52.518611111111_N_13.408333333333_E_region:DE-BE_type:city(3469849)

Thanks very much! That seems to also have triggered the process that is re-rendering the tiles when requesting so (i.e. with /dirty at the end of a single tile's URL).
I'm not sure whether we ever had an automatic tile expiration process set up or if that was just ideas floating around on the mailing list... I'll try to keep an eye on it, but maybe I should rather port over the hikebikemap style to work with the "new setup".

This seems to be down again, e.g. https://tools.wmflabs.org/geohack/geohack.php?pagename=Berlin&language=de&params=52.518611111111_N_13.408333333333_E_region:DE-BE_type:city%283469849%29 doesn't show tiles.

@cmarqu, Italian and Russian wikis have already switched GeoHack to the much more stable maps.wikimedia.org, and English should be switched soon as well (demo) - have you considered switching DE wiki?

• GeoTemplate (you can try it in a sandbox first)
• GeoHack.js -- IT & RU wiki's javascript code is more up to date than EN

@Yurik WikiVoyage is using the MapSources extension which in turn depends on this service via the slippymap tag. What should WikiVoyage do?

@Kghbln, en & ru wikivoyage has already switched to the new maps (example). If MapSources/slippymap uses leaflet or openlayers to get tiles, it should be fairly trivial to retarget them to the new service. Btw, I am not saying we should kill all maps experimentation in labs -- au contraire -- labs is what feeds new development. But labs are by their nature much less stable and prone to issues, thus projects should migrate to production as soon as they are ready.

In T103272#1965106, @cmarqu wrote:

This seems to be down again, e.g. https://tools.wmflabs.org/geohack/geohack.php?pagename=Berlin&language=de&params=52.518611111111_N_13.408333333333_E_region:DE-BE_type:city%283469849%29 doesn't show tiles.

apache was not working for some reason. Fixed, I am investigating what happened

@Yurik , @Kolossos , the main reason I prefer to keep the way they are now on ro.wp is the lack of other points except the current one on the map, like for kml-on-ol.php Do you have any examples on how to do that or, can you move that service to serve tiles from maps.Wikimedia.Org?

@Strainu, the maps.wikimedia.org only offers tile service, just like the (a|b|c).toolserver.org, so swapping one for another should not change the functionality like pushpins and extra layers added by kml-on-ol. For example, you can see it by switching between different backgrounds of the wiwosm kml tool by clicking the little "+" sign in the top right, and switching to "maps.wikimedia".

@Yurik Thanks for your insight.

If MapSources/slippymap uses leaflet or openlayers to get tiles

Yeah the slippymap tag uses openlayers to get the tiles. Probably it will be a good idea to create a task for it so that the tiles are picked up from the new location at maps.wikimedia.org. Keeping fingers crossed.

In T103272#1896916, @Yurik wrote:

@scfc - I'm working on that as part of the Kartographer extension. See demo here. (it can be made into a popup fairly easily later)

I suppose that would be the <maplink> tag? Is there an existing task that tracks converting the current gadget(s) to use Kartographer or should I create one?

I just noticed there are still a lot of hits for these on the toolserver-legacy instance, there are requests for a.toolserver, b.toolserver c.toolserver from a 3rd party Android app *User agent: Dalvik".

In T103272#1965254, @akosiaris wrote:

In T103272#1965106, @cmarqu wrote:

This seems to be down again, e.g. https://tools.wmflabs.org/geohack/geohack.php?pagename=Berlin&language=de&params=52.518611111111_N_13.408333333333_E_region:DE-BE_type:city%283469849%29 doesn't show tiles.

apache was not working for some reason. Fixed, I am investigating what happened

Could you please give it a kick again? (Yesterday, after some time of outage, it started working again, but today, it seems to be more prolonged.)

@madhuvishy Probably an aftermath of the migration ? Is it done (and the only thing required is a VM reboot)? Or not yet ?

@akosiaris The migration is all done

Works gain, thanks.

I 've restarted maps-tiles3 VM on the maps project for what is worth.