GeoServer och PostGIS: VPN-vägen som spelar roll är serverns

Att din laptop når GeoServer säger inget om huruvida GeoServer når PostGIS. Jämför de två ursprungen, cachegränsen och datalagrets egen källa.

Du öppnar lagret i QGIS och det ritas ut. En kollega på samma VPN får ett fel för samma lager. Någon drar slutsatsen att VPN:en är trasig, och nästa timme går åt till att flytta en databas eller öppna en port som aldrig behövde något av det. Begäran från skrivbordet och den fråga GeoServer skickar till PostGIS utgår från olika maskiner, i olika nätverksnamnrymder, med olika inloggningsuppgifter. Att skilja de två vägarna åt är det mesta av diagnosen.

Två anslutningar, två ursprung

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

Den andra pilen ärver inte den första datorns tunnel. En GeoServer i en container har containerns nätverksstack, inte värdens, och en container på ett bryggat nätverk kan nå en databas som värden inte når, eller tvärtom. Så samma användare kan lyckas och misslyckas inom en och samma session, beroende på om svaret kom från cachen eller från en färsk fråga.

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

Hitta steget som faktiskt misslyckades

En avvisning på tjänstenivå, en bildbegäran som inte når sitt datalager och ett behörighetsproblem i ett lager ser likadana ut i en webbläsarflik och helt olika ut i serverloggen. Be om den specifika operationen och läs sedan GeoServers egen händelse för samma tidsstämpel.

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"

Ett 200 från den andra begäran med en rimlig bild bevisar att datalagret svarade. Ett 200 med ett service exception-dokument bevisar att det inte gjorde det, och undantagstexten namnger oftast storen i stället för klienten.

Läs datalagret från serverns sida

Den PostGIS-referens från GeoServer listar vad storen behöver: värd, port, databas och inloggningsuppgifter. Allt detta beskriver den anslutning GeoServer öppnar. Inget av det beskriver en inloggning från skrivbordsklienten. Läs de fyra fälten som ett påstående om serverns nätverkskontext, och hela klassen av ärenden där »det funkar hos dem« blir hanterbar.

Det är därför localhost i ett datalager är ett så vanligt misstag. Det betyder GeoServer-processens egen nätverkskontext. Om GeoServer kör i Docker medan PostGIS kör på värden, localhost pekar in i containern och hittar inget, och ingen VPN-konfiguration ändrar det.

Kontrollera på servern rutten, lyssnaren och autentiseringspolicyn i den ordningen. PostgreSQLs värdbaserade autentisering matchar den källadress den ser, som en gateway kan översätta, så att lägga till en klient-VPN-pool i HBA-filen lagar sällan en anslutning på serversidan. Testa som servern skulle göra: samma värd, samma port, samma användare. Om det testet lyckas medan GeoServer fortfarande misslyckas, sitter skillnaden i proceskontexten och inte i databasen.

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

Pooler och cachar håller tillstånd över ändringar

Anslutningspooler i datalagret håller sockets öppna. En tunnel som kom upp en timme efter att poolen skapades ger inte nödvändigtvis poolen en ny väg, och en inaktiv anslutning kan sitta kvar på en död rutt tills en validering eller en timeout avslutar den. Kontrollera den installerade storens valideringsinställningar i stället för att anta återhämtning, och undvik frestelsen att starta om hela tjänsten innan du vet vilket lager som misslyckades.

Tile-cachar skapar spegelbilden av det problemet: de kan servera en korrekt utseende karta långt efter att databasanslutningen bröts. Att tömma cachen för att »se om det hjälper« förstör det enda bevis som hade berättat vilken väg som var levande.

Lämna över med båda ursprungen namngivna

Beskrivningen som ger en snabb rättning namnger två saker: klientbegäran som nådde GeoServer, och den backend-operation som GeoServer inte kunde slutföra. Med båda kan rätt ägare reparera vägen som misslyckades. Med bara den första är den naturliga rättningen att exponera databasen publikt, vilket löser ärendet genom att skapa ett värre problem.

Notera lagret, svarskoden, undantaget på serversidan och den container eller värd som producerade det. Det är fyra rader, och det tar bort tvetydigheten helt.

Relaterade artiklar