GeoServer i PostGIS: el camí VPN que importa és el del servidor
Que el teu portàtil arribi a GeoServer no di res sobre si GeoServer arriba a PostGIS. Compara els dos orígens, la frontera de la memòria cau i la font pròpia del magatzem de dades.
Obres la capa al QGIS i es dibuixa. Un company a la mateixa VPN rep un error per a la mateixa capa. Algú conclou que la VPN està trencada, i l’hora següent se’n va a moure una base de dades o a exposar un port que no en va necessitar mai cap de les dues coses. La petició de l’escriptori i la consulta que GeoServer fa a PostGIS surten de màquines diferents, en espais de noms de xarxa diferents, amb credencials diferents. Separar aquests dos camins és la major part del diagnòstic.
Dues connexions, dos orígens
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listenerLa segona fletxa no hereta el túnel del primer ordinador. Un GeoServer en un contenidor té la pila de xarxa del contenidor, no la de l’amfitrió, i un contenidor en una xarxa pont pot arribar a una base de dades que l’amfitrió no arriba, o al revés. Així, el mateix usuari pot encertar i fallar dins d’una mateixa sessió, segons si la resposta va venir de la memòria cau o d’una consulta nova.
| What you tested | What it proves |
|---|---|
Portal page or GetCapabilities | HTTP reachability to GeoServer only |
| A tile served from cache | nothing about the database |
GetMap for an uncached layer | a datastore query had to happen |
Trobar el pas que realment va fallar
Un rebuig a nivell de servei, una petició d’imatge que no arriba al seu magatzem de dades i un problema de permisos en una capa s’assemblen en una pestanya del navegador i són completament diferents al registre del servidor. Demana l’operació concreta i després llegeix l’esdeveniment propi de GeoServer per a la mateixa marca de temps.
curl -s -o /dev/null -w '%{http_code}\n' \
"https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetCapabilities"
curl -s -o /tmp/tile.png -w '%{http_code} %{size_download}\n' \
"https://gis.example.com/geoserver/wms?service=WMS&version=1.3.0&request=GetMap&layers=corp:parcels&bbox=-13650000,4500000,-13600000,4550000&width=256&height=256&srs=EPSG:3857&format=image/png"Un 200 de la segona petició amb una imatge plausible demostra que el magatzem de dades va respondre. Un 200 amb un document d’excepció de servei demostra que no ho va fer, i el text de l’excepció sol nomenar el magatzem i no el client.
Llegir el magatzem de dades des del costat del servidor
La referència PostGIS de GeoServer enumera què necessita el magatzem: amfitrió, port, base de dades i credencials. Tot això descriu la connexió que GeoServer obre. Res d’això descriu un inici de sessió del client d’escriptori. Llegeix aquests quatre camps com una afirmació sobre el context de xarxa del servidor, i tota la classe de tiquets de «a ells els funciona» es torna manejable.
Per això localhost en un magatzem de dades és un error tan comú. Significa el context de xarxa del propi procés de GeoServer. Si GeoServer s’executa en Docker mentre PostGIS s’executa a l’amfitrió, localhost apunta dins del contenidor i no troba res, i cap configuració de VPN canvia això.
Al servidor, comprova la ruta, l’oient i la política d’autenticació en aquest ordre. L’autenticació basada en l’amfitrió de PostgreSQL compara l’adreça d’origen que observa, que una passarel·la pot traduir, així que afegir un conjunt de VPN de clients al fitxer HBA rares vegades arregla una connexió del costat del servidor. Prova com ho faria el servidor: mateix amfitrió, mateix port, mateix usuari. Si aquesta prova surt bé mentre GeoServer continua fallant, la diferència és al context del procés i no a la base de dades.
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'Els conjunts i les memòries cau mantenen estat entre canvis
Els conjunts de connexions del magatzem de dades mantenen sockets oberts. Un túnel que va pujar una hora després de crear el conjunt no dóna necessàriament un camí nou al conjunt, i una connexió inactiva pot quedar-se en una ruta morta fins que una validació o un temps d’espera la tanqui. Consulta la configuració de validació del magatzem instal·lat en lloc de suposar una recuperació, i evita la temptació de reiniciar tot el servei abans de saber quina capa va fallar.
Les memòries cau de teseles creen la imatge inversa d’aquest problema: poden servir un mapa d’aspecte correcte molt després que la connexió amb la base de dades s’hagi trencat. Buidar la memòria cau per «veure si ajuda» destrueix l’única prova que t’hauria dit quin camí era viu.
Passar el cas nomenant els dos orígens
La descripció que aconsegueix una correcció ràpida nomena dues coses: la petició del client que va arribar a GeoServer, i l’operació de backend que GeoServer no va poder completar. Amb totes dues, el propietari correcte pot reparar el camí que va fallar. Amb només la primera, la correcció natural és exposar la base de dades públicament, cosa que resol el tiquet creant un problema pitjor.
Anota la capa, el codi de resposta, l’excepció del costat del servidor i el contenidor o amfitrió que la va produir. Són quatre línies, i eliminen l’ambigüitat del tot.