GeoServer og PostGIS: Den VPN-rute, der betyder noget, er serverens

Du åbner laget i QGIS, og det tegnes. En kollega på samme VPN får en fejl for samme lag. Nogen konkluderer, at VPN’en er i stykker, og den næste time går med at flytte en database eller åbne en port, som aldrig havde brug for nogen af delene. Forespørgslen fra skrivebordet og den forespørgsel, GeoServer sender til PostGIS, starter på forskellige maskiner, i forskellige netværksnavnerum, med forskellige legitimationsoplysninger. At skille de to veje ad er det meste af diagnosen.

To forbindelser, to oprindelser

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

Den anden pil arver ikke den første computers tunnel. En GeoServer i en container har containerens netværksstak, ikke værtens, og en container på et broet netværk kan nå en database, som værten ikke kan nå, eller omvendt. Så den samme bruger kan lykkes og fejle i samme session, alt efter om svaret kom fra cachen eller fra en frisk forespørgsel.

Find det trin, der faktisk fejlede

En afvisning på tjenesteniveau, en billedforespørgsel, der ikke når sin datastore, og et tilladelsesproblem i et lag ser ens ud i en browserfane og helt anderledes ud i serverloggen. Bed om den konkrete operation, og læs derefter GeoServers egen hændelse for samme tidsstempel.

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"

Et 200 fra den anden forespørgsel med et plausibelt billede beviser, at datastoren svarede. Et 200 med et service-exception-dokument beviser, at den ikke gjorde, og undtagelsesteksten nævner som regel storen frem for klienten.

Læs datastoren fra serverens side

Den PostGIS-reference fra GeoServer lister, hvad storen har brug for: vært, port, database og legitimationsoplysninger. Alt dette beskriver den forbindelse, GeoServer åbner. Intet af det beskriver et login fra skrivebordsklienten. Læs de fire felter som en udtalelse om serverens netværkskontekst, og hele klassen af »hos dem virker det«-sager bliver håndterbar.

Derfor er localhost i en datastore så almindelig en fejl. Det betyder GeoServer-processens egen netværkskontekst. Hvis GeoServer kører i Docker, mens PostGIS kører på værten, localhost peger ind i containeren og finder intet, og ingen VPN-konfiguration ændrer det.

Tjek på serveren ruten, listeneren og godkendelsespolitikken i den rækkefølge. PostgreSQLs værtsbaserede godkendelse matcher den kildeadresse, den ser, som en gateway kan oversætte, så en klient-VPN-pulje i HBA-filen retter sjældent en forbindelse på serversiden. Test som serveren ville gøre: samme vært, samme port, samme bruger. Hvis den test lykkes, mens GeoServer stadig fejler, ligger forskellen i proceskonteksten og ikke 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'

Puljer og caches holder tilstand på tværs af ændringer

Forbindelsespuljer i datastoren holder sockets åbne. En tunnel, der kom op en time efter puljens oprettelse, giver ikke nødvendigvis puljen en ny vej, og en inaktiv forbindelse kan blive siddende på en død rute, indtil en validering eller en timeout afslutter den. Tjek den installerede stores valideringsindstillinger i stedet for at antage, at den kommer sig, og undgå fristelsen til at genstarte hele tjenesten, før du ved, hvilket lag der fejlede.

Tile-caches skaber spejlbilledet af det problem: de kan servere et korrekt udseende kort længe efter, at databaseforbindelsen blev brudt. At tømme cachen for »at se, om det hjælper« ødelægger det ene bevis, der ville have fortalt dig, hvilken vej der var levende.

Overdrag med begge oprindelser navngivet

Den beskrivelse, der giver en hurtig rettelse, nævner to ting: klientforespørgslen, der nåede GeoServer, og den backend-operation, GeoServer ikke kunne gennemføre. Med begge kan den rigtige ejer reparere den vej, der fejlede. Med kun den første er den naturlige rettelse at eksponere databasen offentligt, hvilket løser sagen ved at skabe et værre problem.

Notér laget, svarkoden, undtagelsen på serversiden og den container eller vært, der producerede den. Det er fire linjer, og det fjerner tvetydigheden helt.