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 पूर्ण करू शकला नाही ती बॅकएंड क्रिया. दोन्ही असल्यास योग्य मालक अयशस्वी झालेला मार्ग दुरुस्त करू शकतो. फक्त पहिले असल्यास नैसर्गिक दुरुस्ती म्हणजे डेटाबेस सार्वजनिकपणे उघडणे, जे तिकीट अधिक वाईट समस्या निर्माण करून सोडवते.
लेयर, प्रतिसाद कोड, सर्व्हर-बाजूचा अपवाद आणि तो तयार करणारा कंटेनर किंवा होस्ट नोंदवा. या चार ओळी आहेत, आणि त्या संदिग्धता पूर्णपणे दूर करतात.