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 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

وہ مرحلہ تلاش کریں جو واقعی ناکام ہوا

سروس کی سطح پر مسترد ہونا، ایسی تصویر کی درخواست جو اپنے ڈیٹا اسٹور تک نہیں پہنچتی، اور ایک لیئر میں اجازت کا مسئلہ براؤزر ٹیب میں ایک جیسے لگتے ہیں اور سرور لاگ میں بالکل مختلف۔ مخصوص کارروائی طلب کریں، پھر اسی ٹائم اسٹیمپ کے لیے سرور کا اپنا ایونٹ پڑھیں۔

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 مکمل نہ کر سکا۔ دونوں کے ساتھ صحیح مالک ناکام ہونے والا راستہ ٹھیک کر سکتا ہے۔ صرف پہلے کے ساتھ قدرتی مرمت ڈیٹا بیس کو عوامی طور پر کھولنا ہے، جو ٹکٹ کو اس سے بدتر مسئلہ بنا کر حل کرتا ہے۔

لیئر، جواب کا کوڈ، سرور کی طرف کا استثنا اور وہ کنٹینر یا میزبان جس نے اسے پیدا کیا، نوٹ کریں۔ یہ چار سطریں ہیں، اور یہ ابہام کو مکمل طور پر ختم کر دیتی ہیں۔

متعلقہ مضامین