GeoServer e PostGIS: il percorso VPN che conta è quello del server

Che il tuo portatile raggiunga GeoServer non dice nulla sul fatto che GeoServer raggiunga PostGIS. Confronta le due origini, il confine della cache e la fonte stessa del datastore.

Apri il layer in QGIS e viene renderizzato. Un collega sulla stessa VPN riceve un errore per lo stesso layer. Qualcuno conclude che la VPN è guasta, e l’ora successiva se ne va spostando un database o esponendo una porta che non aveva bisogno né dell’uno né dell’altra. La richiesta dal desktop e la query che GeoServer fa a PostGIS partono da macchine diverse, in namespace di rete diversi, con credenziali diverse. Separare questi due percorsi è gran parte della diagnosi.

Due connessioni, due origini

QGIS  ->  client's permitted path (often the VPN)  ->  GeoServer listener
GeoServer -> server's permitted path  ->  PostGIS listener

La seconda freccia non eredita il tunnel del primo computer. Un GeoServer in un container ha lo stack di rete del container, non quello dell’host, e un container su una rete bridge può raggiungere un database che l’host non raggiunge, o il contrario. Così lo stesso utente può riuscire e fallire nella stessa sessione, a seconda che la risposta sia arrivata dalla cache o da una query fresca.

What you testedWhat it proves
Portal page or GetCapabilitiesHTTP reachability to GeoServer only
A tile served from cachenothing about the database
GetMap for an uncached layera datastore query had to happen

Trovare il passo che ha fallito davvero

Un rifiuto a livello di servizio, una richiesta di immagine che non raggiunge il suo datastore e un problema di permessi su un layer sembrano simili in una scheda del browser e sono del tutto diversi nel log del server. Chiedi l’operazione specifica, poi leggi l’evento di GeoServer per lo stesso timestamp.

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 della seconda richiesta con un’immagine plausibile dimostra che il datastore ha risposto. Un 200 con un documento di service exception dimostra che non l’ha fatto, e il testo dell’eccezione di solito nomina lo store invece del client.

Leggere il datastore dal lato del server

La guida PostGIS di GeoServer elenca ciò che serve allo store: host, porta, database e credenziali. Tutto questo descrive la connessione che GeoServer apre. Niente di tutto questo descrive un accesso da parte del client desktop. Leggi quei quattro campi come un’affermazione sul contesto di rete del server, e l’intera classe dei ticket «a loro funziona» diventa gestibile.

Ecco perché localhost in un datastore è un errore così comune. Significa il contesto di rete del processo GeoServer stesso. Se GeoServer gira in Docker mentre PostGIS gira sull’host, localhost punta dentro il container e non trova nulla, e nessuna configurazione VPN cambia questo.

Sul server, controlla la rotta, il listener e la policy di autenticazione in quest’ordine. L’autenticazione basata sull’host di PostgreSQL confronta l’indirizzo di origine che osserva, che un gateway può tradurre, quindi aggiungere un pool VPN client al file HBA raramente risolve una connessione lato server. Prova come farebbe il server: stesso host, stessa porta, stesso utente. Se quel test riesce mentre GeoServer fallisce ancora, la differenza è nel contesto del processo e non nel database.

ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'

I pool e le cache mantengono stato attraverso i cambiamenti

I pool di connessioni del datastore tengono le socket aperte. Un tunnel salito un’ora dopo la creazione del pool non dà necessariamente al pool un nuovo percorso, e una connessione inattiva può restare su una rotta morta finché una validazione o un timeout non la chiude. Controlla le impostazioni di validazione dello store installato invece di dare per scontato il recupero, e resisti alla tentazione di riavviare l’intero servizio prima di sapere quale layer ha fallito.

Le cache di tile creano l’immagine speculare di quel problema: possono servire una mappa dall’aspetto corretto molto tempo dopo che la connessione al database si è rotta. Svuotare la cache per «vedere se aiuta» distrugge l’unica prova che ti avrebbe detto quale percorso era vivo.

Passare il caso nominando entrambe le origini

La descrizione che ottiene una correzione rapida nomina due cose: la richiesta client che ha raggiunto GeoServer e l’operazione di backend che GeoServer non è riuscito a completare. Con entrambe, il proprietario giusto può riparare il percorso che ha fallito. Con solo la prima, la correzione naturale è esporre il database pubblicamente, il che risolve il ticket creando un problema peggiore.

Annota il layer, il codice di risposta, l’eccezione lato server e il container o host che l’ha prodotta. Sono quattro righe, e tolgono del tutto l’ambiguità.

Articoli correlati