GeoServer e PostGIS: a ruta VPN que importa é a do servidor

Que o teu portátil chegue a GeoServer non di nada sobre se GeoServer chega a PostGIS. Compara as dúas orixes, a fronteira da caché e a propia fonte do almacén de datos.

Abres a capa en QGIS e debúxase. Un compañeiro na mesma VPN recibe un erro para a mesma capa. Alguén conclúe que a VPN está rota, e a hora seguinte vaise en mover unha base de datos ou en expor un porto que nunca necesitou ningunha das dúas cousas. A petición do escritorio e a consulta que GeoServer fai a PostGIS saen de máquinas distintas, en espazos de nomes de rede distintos, con credenciais distintas. Separar esas dúas rutas é a maior parte do diagnóstico.

Dúas conexións, dúas orixes

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

A segunda frecha non herda o túnel do primeiro ordenador. Un GeoServer nun contedor ten a pila de rede do contedor, non a do hóspede, e un contedor nunha rede ponte pode acadar unha base de datos que o hóspede non acada, ou o contrario. Así, o mesmo usuario pode acertar e fallar dentro dunha mesma sesión, segundo se a resposta veu da caché ou dunha consulta nova.

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

Atopa o paso que fallou de verdade

Un rexeitamento a nivel de servizo, unha petición de imaxe que non chega ao seu almacén de datos e un problema de permisos nunha capa parecen iguais nunha lapela do navegador e completamente distintos no rexistro do servidor. Pide a operación concreta e despois le o evento propio de GeoServer para a mesma marca de tempo.

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 da segunda petición cunha imaxe plausible proba que o almacén de datos respondeu. Un 200 cun documento de excepción de servizo proba que non o fixo, e o texto da excepción adoita nomear o almacén en vez do cliente.

Ler o almacén de datos desde o lado do servidor

A referencia PostGIS de GeoServer enumera o que necesita o almacén: hóspede, porto, base de datos e credenciais. Todo iso describe a conexión que GeoServer abre. Nada diso describe un inicio de sesión desde o cliente de escritorio. Le eses catro campos como unha afirmación sobre o contexto de rede do servidor, e toda a clase de tíckets de «a eles funciona» vólvese tratable.

Por iso localhost nun almacén de datos é un erro tan común. Significa o contexto de rede do propio proceso de GeoServer. Se GeoServer corre en Docker mentres PostGIS corre no hóspede, localhost apunta dentro do contedor e non atopa nada, e ningunha configuración de VPN cambia iso.

No servidor, comproba a ruta, o listener e a política de autenticación nesa orde. A autenticación baseada no hóspede de PostgreSQL compara o enderezo de orixe que observa, que unha pasarela pode traducir, así que engadir un conxunto de VPN de clientes ao ficheiro HBA raramente arranxa unha conexión do lado do servidor. Proba como o faría o servidor: mesmo hóspede, mesmo porto, mesmo usuario. Se esa proba sae ben mentres GeoServer segue fallando, a diferenza está no contexto do proceso e non na base de datos.

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

Os conxuntos e as cachés manteñen estado entre cambios

Os conxuntos de conexións do almacén de datos manteñen sockets abertos. Un túnel que subiu unha hora despois de crear o conxunto non lle dá necesariamente unha ruta nova ao conxunto, e unha conexión inactiva pode quedar nunha ruta morta ata que unha validación ou un tempo de espera a peche. Consulta a configuración de validación do almacén instalado en vez de supoñer unha recuperación, e evita a tentación de reiniciar todo o servizo antes de saber que capa fallou.

As cachés de teselas crean a imaxe inversa dese problema: poden servir un mapa de aspecto correcto moito despois de que a conexión coa base de datos se rompese. Baleirar a caché para «ver se axuda» destrúe a única proba que che diría que ruta estaba viva.

Pasar o caso nomeando as dúas orixes

A descrición que consegue unha corrección rápida nomea dúas cousas: a petición do cliente que chegou a GeoServer, e a operación de backend que GeoServer non puido completar. Coas dúas, o propietario correcto pode reparar a ruta que fallou. Só coa primeira, a corrección natural é expor a base de datos publicamente, o que resolve o tícket creando un problema peor.

Anota a capa, o código de resposta, a excepción do lado do servidor e o contedor ou hóspede que a produciu. Son catro liñas, e eliminan a ambigüidade por completo.

Artigos relacionados