When it comes to the maps team/RI team testing the existing instructions and cleaning them up, the following parts of the new instructions might be useful, as well as the following notes.
- Any instructions that reference the "ct" database will need to run on the "gis" database, but should not be followed blindly. Different extensions and tables are present in the two setups.
- Anything using process-osm-data should not be run. That script runs the commands in the readmes of cleartables, meddo, brighmed, and kartotherian. You could also run them by hand. A script with the instructions for osm-bright.tm2source and kartotherian is needed instead. Because there are fewer components, this is simpler, and a script might not be necessary.
Of the instructions on https://wikitech.wikimedia.org/wiki/Maps/Loading, these sections could be applied to osm-bright.tm2source and osm-bright.tm2:
- Downloading sections 1-2
- Database checks (The first occurance of checks)
- Database setup
- Database checks (2nd occurance) rendering tables, slim tables, and rendering read access
|operations/puppet : production||Use backports version of osm2pgsql on Stretch for improved memory handling|
|Resolved||MSantos||T152196 Kartotherian snapshots always return low DPI images|
|Resolved||Gehel||T198622 migrate maps servers to stretch with the current style|
|Resolved||Mholloway||T198485 Verify loading instructions for existing styles on Stretch|
|Resolved||Mholloway||T172090 move maps-test cluster to cloud infrastructure|
|Resolved||debt||T171746 Determining the plan for the maps-test cluster|
First issue: I've dowloaded and checksummed the OSM full planet PBF for 6/25. Following the https://wikitech.wikimedia.org/wiki/Maps#Importing_database instructions (since process_osm_data is unavailable), I run the osm2pgsql command, with the following result:
Osm2pgsql failed due to ERROR: Connection to database failed: FATAL: no pg_hba.conf entry for host "10.192.16.34", user "osmimporter", database "gis", SSL off
Looking at pg_hba.conf, there is an entry for user osmimporter, but for the IP range 127.0.0.1/32. Should something be updated in Puppet to fix this? Can I just update the file manually for now?
Separately, I notice there's an osm-initial-import shell script. Should I be using this instead?
using localhost instead of maps-test2003 should resolve the issue. It makes some sense to only allow osmupdater on 127.0.0.1. Ideally, we should probably move to unix sockets, but not for right now.