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 முடிக்க முடியாத பின்தளச் செயல்பாடு. இரண்டும் இருந்தால் சரியான உரிமையாளர் தோல்வியடைந்த பாதையைச் சரிசெய்ய முடியும். முதலில் ஒன்று மட்டும் இருந்தால் இயல்பான திருத்தம் தரவுத்தளத்தைப் பொதுவில் வெளிப்படுத்துவது, அது சீட்டை மிக மோசமான சிக்கலை உருவாக்கி தீர்க்கிறது.
அடுக்கு, பதில் குறியீடு, சேவையகப் பக்க விதிவிலக்கு மற்றும் அதை உருவாக்கிய கொள்கலன் அல்லது புரவலனைக் குறிப்பெடுங்கள். அவை நான்கு வரிகள், அவை தெளிவின்மையை முழுமையாக நீக்குகின்றன.