GeoServer અને PostGIS: ખરો VPN માર્ગ સર્વરનો છે
તમારો લેપટોપ GeoServer સુધી પહોંચે છે એથી એ નથી કહેવાતું કે GeoServer PostGIS સુધી પહોંચે છે કે નહીં. બંને સ્રોત, કૅશની સીમા અને ડેટા સ્ટોરનો પોતાનો સ્રોત સરખાવો.
તમે QGISમાં લેયર ખોલો છો અને તે રેન્ડર થાય છે. એ જ VPN પરનો સહકર્મી એ જ લેયર માટે ભૂલ મેળવે છે. કોઈ નિષ્કર્ષ કાઢે છે કે VPN બગડેલું છે, અને પછીનો કલાક કોઈ ડેટાબેઝ ખસેડવામાં કે એવો પોર્ટ ખોલવામાં જાય છે જેને કદી એ બંનેની જરૂર નહોતી. ડેસ્કટોપથી જતી વિનંતી અને GeoServer જે ક્વેરી PostGISને કરે છે, તે જુદા જુદા મશીનથી, જુદા જુદા નેટવર્ક નામ-અવકાશમાં, જુદા જુદા ક્રેડેન્શિયલ સાથે નીકળે છે. આ બે માર્ગ અલગ કરવો એ જ નિદાનનો મોટો ભાગ છે.
બે કનેક્શન, બે સ્રોત
QGIS -> client's permitted path (often the VPN) -> GeoServer listener
GeoServer -> server's permitted path -> PostGIS listenerબીજું તીર પહેલા કમ્પ્યુટરની ટનલ વારસામાં લેતું નથી. કન્ટેનરમાં ચાલતું GeoServer કન્ટેનરનું નેટવર્ક સ્ટેક ધરાવે છે, હોસ્ટનું નહીં, અને બ્રિજ નેટવર્ક પરનું કન્ટેનર એવા ડેટાબેઝ સુધી પહોંચી શકે જ્યાં હોસ્ટ પહોંચતું નથી, અથવા ઊલટું. તેથી એ જ વપરાશકર્તા એક જ સત્રમાં સફળ અને નિષ્ફળ બંને થઈ શકે, જવાબ કૅશમાંથી આવ્યો કે તાજી ક્વેરીમાંથી તેના પર આધાર રાખીને.
| What you tested | What it proves |
|---|---|
Portal page or GetCapabilities | HTTP reachability to GeoServer only |
| A tile served from cache | nothing about the database |
GetMap for an uncached layer | a datastore query had to happen |
ખરેખર નિષ્ફળ ગયેલું પગલું શોધો
સેવા-સ્તરનો અસ્વીકાર, પોતાના ડેટા સ્ટોર સુધી ન પહોંચતી ઇમેજ વિનંતી, અને એક લેયરમાં પરવાનગીની સમસ્યા બ્રાઉઝર ટૅબમાં સરખી દેખાય છે અને સર્વર લોગમાં સાવ જુદી. ચોક્કસ ક્રિયા માગો, પછી એ જ સમય-છાપ માટે સર્વરની પોતાની ઘટના વાંચો.
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 સાબિત કરે છે કે ડેટા સ્ટોરે જવાબ આપ્યો. સેવા-અપવાદ દસ્તાવેજ સાથેનો 200 સાબિત કરે છે કે આપ્યો નહીં, અને અપવાદનું લખાણ સામાન્ય રીતે ક્લાયન્ટને બદલે સ્ટોરનું નામ લે છે.
ડેટા સ્ટોર સર્વરની બાજુથી વાંચો
GeoServerનો PostGIS સંદર્ભ સ્ટોરને શું જોઈએ તે સૂચિબદ્ધ કરે છે: હોસ્ટ, પોર્ટ, ડેટાબેઝ અને ક્રેડેન્શિયલ. આ બધું GeoServer જે કનેક્શન ખોલે છે તેનું વર્ણન કરે છે. આમાંથી કંઈ પણ ડેસ્કટોપ ક્લાયન્ટમાંથી લોગિન થવાનું વર્ણન કરતું નથી. આ ચાર ક્ષેત્રોને સર્વરના નેટવર્ક સંદર્ભ વિશેનું વિધાન ગણો, અને «તેમને ત્યાં ચાલે છે» ટિકિટનો આખો વર્ગ ઉકેલી શકાય તેવો બની જાય છે.
તેથી જ localhost ડેટા સ્ટોરમાં આટલી સામાન્ય ભૂલ છે. તેનો અર્થ GeoServer પ્રક્રિયાનો પોતાનો નેટવર્ક સંદર્ભ. જો GeoServer Dockerમાં ચાલે છે જ્યારે PostGIS હોસ્ટ પર ચાલે છે, localhost કન્ટેનરની અંદર નિર્દેશ કરે છે અને કંઈ જ શોધતું નથી, અને કોઈ પણ VPN રૂપરેખાંકન તેને બદલતું નથી.
સર્વર પર માર્ગ, શ્રોતા અને પ્રમાણીકરણ નીતિ એ જ ક્રમમાં તપાસો. PostgreSQLનું હોસ્ટ-આધારિત પ્રમાણીકરણ જે સ્રોત સરનામું જુએ છે તેની સાથે મેળવે છે, જે ગેટવે ભાષાંતરિત કરી શકે છે, તેથી HBA ફાઇલમાં ક્લાયન્ટ VPN પૂલ ઉમેરવો સર્વર-બાજુનું કનેક્શન ભાગ્યે જ સુધારે છે. સર્વર જેમ કરે તેમ ચકાસો: એ જ હોસ્ટ, એ જ પોર્ટ, એ જ વપરાશકર્તા. જો એ કસોટી સફળ થાય અને GeoServer હજી નિષ્ફળ જાય, તો ફરક ડેટાબેઝમાં નહીં પણ પ્રક્રિયાના સંદર્ભમાં છે.
ip route get 10.20.5.11
ss -tnp | grep 5432
psql "host=10.20.5.11 dbname=gis user=geoserver" -c 'select 1'પૂલ અને કૅશ ફેરફારો દરમિયાન સ્થિતિ રાખે છે
ડેટા સ્ટોરના કનેક્શન પૂલ સૉકેટ ખુલ્લા રાખે છે. પૂલ બન્યાના કલાક પછી આવેલી ટનલ પૂલને નવો માર્ગ આપે જ તેવું નથી, અને નિષ્ક્રિય કનેક્શન મૃત માર્ગ પર પડી રહી શકે જ્યાં સુધી ચકાસણી કે સમયમર્યાદા તેને બંધ ન કરે. સ્થાપિત સ્ટોરની ચકાસણી સેટિંગ્સ જુઓ, પુનઃપ્રાપ્તિ ધારી લેવાને બદલે, અને કયું લેયર નિષ્ફળ ગયું તે જાણ્યા પહેલાં આખી સેવા ફરી ચાલુ કરવાના લોભથી બચો.
ટાઇલ કૅશ આ સમસ્યાની અરીસા-પ્રતિમા બનાવે છે: ડેટાબેઝ કનેક્શન તૂટ્યાના ઘણા સમય પછી પણ તેઓ સાચું દેખાતું નકશું પરોસી શકે છે. કૅશ ખાલી કરવો એટલે «જોઈએ મદદ થાય છે કે નહીં» એ એકમાત્ર પુરાવો નષ્ટ કરે છે જે તમને કહેત કે કયો માર્ગ જીવંત હતો.
બંને સ્રોતનાં નામ લઈને સોંપો
જે વર્ણનને ઝડપી સુધારો મળે છે તે બે વાત કહે છે: GeoServer સુધી પહોંચેલી ક્લાયન્ટ વિનંતી, અને GeoServer પૂરી કરી ન શક્યું તે બૅકએન્ડ ક્રિયા. બંને હોય તો યોગ્ય માલિક નિષ્ફળ ગયેલો માર્ગ સુધારી શકે. ફક્ત પહેલું હોય તો સ્વાભાવિક સુધારો ડેટાબેઝ જાહેરમાં ખોલવો છે, જે ટિકિટને વધુ ખરાબ સમસ્યા બનાવીને ઉકેલે છે.
લેયર, પ્રતિસાદ કોડ, સર્વર-બાજુનો અપવાદ અને તેને બનાવનાર કન્ટેનર કે હોસ્ટ નોંધો. આ ચાર લીટીઓ છે, અને તેઓ અસ્પષ્ટતા સંપૂર્ણપણે દૂર કરે છે.