GeoServer kaj PostGIS: la grava VPN-vojo estas tiu de la servilo

Tio, ke via tekkomputilo atingas GeoServer, diras nenion pri tio, ĉu GeoServer atingas PostGIS. Komparu la du originojn, la kaŝmemoran limon kaj la propran fonton de la datenejo.

Vi malfermas la tavolon en QGIS kaj ĝi bildiĝas. Kolego en la sama VPN ricevas eraron por la sama tavolo. Iu konkludas, ke la VPN estas rompita, kaj la sekva horo pasas per movado de datumbazo aŭ malfermo de pordo, kiu neniam bezonis iun el ambaŭ. La peto de la labortablo kaj la pridemando, kiun GeoServer faras al PostGIS, ekiras de malsamaj maŝinoj, en malsamaj retaj nomspacoj, kun malsamaj akreditaĵoj. Apartigi tiujn du vojojn estas la plej granda parto de la diagnozo.

Du konektoj, du originoj

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

La dua sago ne heredas la tunelon de la unua komputilo. GeoServer en ujo havas la retan stakon de la ujo, ne tiun de la gastiganto, kaj ujo sur ponto-reto povas atingi datumbazon, kiun la gastiganto ne atingas, aŭ inverse. Tial la sama uzanto povas sukcesi kaj malsukcesi en la sama seanco, depende de tio, ĉu la respondo venis el la kaŝmemoro aŭ el freŝa pridemando.

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

Trovu la paŝon, kiu vere malsukcesis

Malakcepto je servo-nivelo, bilda peto, kiu ne atingas sian datenejon, kaj permesa problemo en unu tavolo aspektas simile en retumila langeto kaj tute alie en la servila protokolo. Petu la konkretan operacion, poste legu la propran okazaĵon de GeoServer por la sama tempomarko.

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"

200 el la dua peto kun kredinda bildo pruvas, ke la datenejo respondis. 200 kun servo-escepta dokumento pruvas, ke ĝi ne respondis, kaj la escepta teksto kutime nomas la konservejon anstataŭ la klienton.

Legu la datenejon de la servila flanko

La PostGIS-referenco de GeoServer listigas, kion la konservejo bezonas: gastiganto, pordo, datumbazo kaj akreditaĵoj. Ĉio tio priskribas la konekton, kiun GeoServer malfermas. Nenio el tio priskribas saluton de la labortabla kliento. Legu tiujn kvar kampojn kiel aserton pri la reta kunteksto de la servilo, kaj la tuta klaso de «ĉe ili ĝi funkcias» biletoj fariĝas traktebla.

Jen kial localhost en datenejo estas tiel ofta eraro. Ĝi signifas la retan kuntekston de la GeoServer-procezo mem. Se GeoServer funkcias en Docker dum PostGIS funkcias sur la gastiganto, localhost montras en la ujon kaj trovas nenion, kaj neniu VPN-agordo ŝanĝas tion.

Sur la servilo kontrolu la vojon, la aŭskultanton kaj la aŭtentigan politikon en tiu ordo. La gastiganto-bazita aŭtentigo de PostgreSQL komparas la fontan adreson, kiun ĝi vidas, kiun pordego povas traduki, do aldoni klientan VPN-aron al la HBA-dosiero malofte riparas serviloflankan konekton. Testu tiel, kiel la servilo farus: sama gastiganto, sama pordo, sama uzanto. Se tiu testo sukcesas dum GeoServer ankoraŭ malsukcesas, la diferenco estas en la proceza kunteksto, ne en la datumbazo.

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

Aroj kaj kaŝmemoroj tenas staton tra ŝanĝoj

Konektaroj de la datenejo tenas ingojn malfermitaj. Tunelo, kiu aperis horon post la kreado de la aro, ne nepre donas al la aro novan vojon, kaj senokupa konekto povas resti sur mortinta vojo ĝis validigo aŭ tempolimo ĝin fermos. Kontrolu la validigajn agordojn de la instalita konservejo anstataŭ supozi resaniĝon, kaj evitu la tenton restartigi la tutan servon antaŭ ol vi scias, kiu tavolo malsukcesis.

Kahelaj kaŝmemoroj kreas la spegulan bildon de tiu problemo: ili povas servi ĝuste aspektan mapon longe post kiam la datumbaza konekto rompiĝis. Malplenigi la kaŝmemoron por «vidi, ĉu ĝi helpas» detruas la solan pruvon, kiu dirus al vi, kiu vojo estis viva.

Transdonu kun ambaŭ originoj nomitaj

La priskribo, kiu ricevas rapidan riparon, nomas du aferojn: la klientan peton, kiu atingis GeoServer, kaj la malantaŭan operacion, kiun GeoServer ne povis fini. Kun ambaŭ, la ĝusta posedanto povas ripari la vojon, kiu malsukcesis. Kun nur la unua, la natura ripeto estas malkaŝi la datumbazon publike, kio solvas la bileton kreante pli malbonan problemon.

Notu la tavolon, la respondan kodon, la serviloflankan escepton kaj la ujon aŭ gastiganton, kiu produktis ĝin. Tio estas kvar linioj, kaj ĝi forigas la malklarecon tute.

Rilataj artikoloj