GeoServer en PostGIS: het VPN-pad dat ertoe doet is dat van de server

Je opent de laag in QGIS en hij wordt getekend. Een collega op dezelfde VPN krijgt een fout voor dezelfde laag. Iemand concludeert dat de VPN stuk is, en het volgende uur gaat op aan het verplaatsen van een database of het openzetten van een poort die geen van beide ooit nodig had. Het verzoek vanaf de desktop en de query die GeoServer naar PostGIS stuurt, vertrekken vanaf verschillende machines, in verschillende netwerk-namespaces, met verschillende inloggegevens. Die twee paden scheiden is het grootste deel van de diagnose.

Twee verbindingen, twee herkomsten

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

De tweede pijl erft niet de tunnel van de eerste computer. Een GeoServer in een container heeft de netwerkstack van de container, niet die van de host, en een container op een bridge-netwerk kan een database bereiken die de host niet bereikt, of andersom. Zo kan dezelfde gebruiker binnen één sessie slagen en falen, afhankelijk van of het antwoord uit de cache kwam of uit een verse query.

De stap vinden die echt is mislukt

Een afwijzing op dienstniveau, een afbeeldingsverzoek dat zijn datastore niet bereikt en een rechtenprobleem in één laag lijken in een browsertab op elkaar en zijn in het serverlog volledig verschillend. Vraag om de specifieke bewerking en lees daarna de eigen gebeurtenis van GeoServer voor dezelfde tijdstempel.

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"

Een 200 van het tweede verzoek met een plausibele afbeelding bewijst dat de datastore heeft geantwoord. Een 200 met een service-exception-document bewijst dat hij dat niet deed, en de tekst van de uitzondering noemt meestal de store en niet de client.

De datastore vanaf de serverkant lezen

De PostGIS-referentie van GeoServer somt op wat de store nodig heeft: host, poort, database en inloggegevens. Dat alles beschrijft de verbinding die GeoServer opent. Niets daarvan beschrijft een aanmelding door de desktopclient. Lees die vier velden als een uitspraak over de netwerkcontext van de server, en de hele klasse van „bij hen werkt het”-tickets wordt hanteerbaar.

Daarom is localhost in een datastore zo’n veelgemaakte fout. Het betekent de netwerkcontext van het GeoServer-proces zelf. Als GeoServer in Docker draait terwijl PostGIS op de host draait, localhost wijst naar de binnenkant van de container en vindt niets, en geen enkele VPN-configuratie verandert dat.

Controleer op de server de route, de listener en het authenticatiebeleid in die volgorde. De hostgebaseerde authenticatie van PostgreSQL vergelijkt het bronadres dat zij waarneemt, dat een gateway kan vertalen, dus een client-VPN-pool toevoegen aan het HBA-bestand lost een verbinding aan de serverkant zelden op. Test zoals de server het zou doen: dezelfde host, dezelfde poort, dezelfde gebruiker. Als die test slaagt terwijl GeoServer nog steeds faalt, zit het verschil in de procescontext en niet in de 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'

Pools en caches houden status vast over wijzigingen heen

Verbindingspools van datastores houden sockets open. Een tunnel die een uur na het aanmaken van de pool opkwam geeft de pool niet automatisch een nieuw pad, en een inactieve verbinding kan op een dode route blijven zitten tot een validatie of een time-out hem beëindigt. Controleer de validatie-instellingen van de geïnstalleerde store in plaats van herstel aan te nemen, en weersta de verleiding om de hele dienst te herstarten voordat je weet welke laag is mislukt.

Tegelcaches maken het spiegelbeeld van dat probleem: ze kunnen een correct uitziende kaart nog lang serveren nadat de databaseverbinding is verbroken. De cache leegmaken om „te kijken of het helpt” vernietigt het enige bewijs dat je had verteld welk pad levend was.

Overdragen met beide herkomsten benoemd

De beschrijving die een snelle oplossing oplevert, noemt twee dingen: het clientverzoek dat GeoServer bereikte, en de backend-bewerking die GeoServer niet kon afronden. Met beide kan de juiste eigenaar het pad repareren dat is mislukt. Met alleen het eerste is de voor de hand liggende oplossing de database publiek openzetten, wat het ticket oplost door een erger probleem te scheppen.

Noteer de laag, de responscode, de uitzondering aan de serverkant en de container of host die hem produceerde. Dat zijn vier regels, en ze nemen de dubbelzinnigheid volledig weg.