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 पूरा नहीं कर सका। दोनों के साथ सही स्वामी उस मार्ग को ठीक कर सकता है जो विफल हुआ। केवल पहले के साथ स्वाभाविक सुधार डेटाबेस को सार्वजनिक रूप से खोलना है, जो टिकट को और बुरी समस्या बनाकर हल करता है।
लेयर, प्रतिक्रिया कोड, सर्वर-पक्ष का अपवाद और वह कंटेनर या होस्ट जिसने उसे बनाया, नोट करें। ये चार पंक्तियाँ हैं, और ये अस्पष्टता को पूरी तरह हटा देती हैं।