VPN-এর পিছনে QGIS-কে PostGIS-এ সংযুক্ত করুন: ধাপে ধাপে

QGIS তার ডেটা প্রোভাইডাররা যে পথে পৌঁছাতে পারে সেই পথই পড়ে, তাই চালু থাকা VPN কেবল অর্ধেক ব্যবস্থা। টানেল ডেস্কটপকে একটি রুট ও একটি নাম-সমাধান নীতি দেয়; প্রকল্পটির এখনও প্রয়োজন সার্ভিস এন্ডপয়েন্ট, প্রোভাইডারের প্রোটোকল এবং যে শংসাপত্র সার্ভিসটি গ্রহণ করবে। এগুলি তিনটি আলাদা এন্ট্রি, আর VPN-এর পাবলিক লিসেনার ডেটাবেস ফিল্ডে টাইপ করা এর কোনোটিই নয়। এই নির্দেশিকাটি QGIS ফর্ম থেকে ফেরত আসা সারি পর্যন্ত একটি PostGIS লেয়ার অনুসরণ করে এবং প্রতিটি ধাপ যে সীমা প্রমাণ করে তার নাম দেয়।

VPN থেকে নয়, লেয়ার থেকেই শুরু করুন

প্রতিটি লেয়ার ধরন আলাদা ধরনের এন্ডপয়েন্টে পৌঁছায়। একটি PostGIS লেয়ার হোস্ট, পোর্ট, ডেটাবেস ও রোল নিয়ে PostgreSQL সংযোগ খোলে। একটি WMS বা WFS লেয়ার একটি সার্ভিস URL আনে এবং তারপর একটি ক্যাপাবিলিটিজ নথি পার্স করে। নেটওয়ার্ক শেয়ারে থাকা shapefile-এর কেবল একটি ফাইল পাথ দরকার যা অপারেটিং সিস্টেম খুলতে পারে। যেহেতু এগুলি তিনটি ভিন্ন প্রক্রিয়া, তাই খালি প্রকল্প আপনাকে কিছুই বলে না যতক্ষণ না জানেন কোনটি ডিবাগ করছেন।

GIS অপারেটরের কাছে এন্ডপয়েন্ট, পোর্ট, প্রয়োজনীয় পরিচয় এবং আপনার অ্যাকাউন্টে প্রযোজ্য অ্যাক্সেস নীতি জিজ্ঞাসা করুন। ডিপ্লয়মেন্ট যখন প্রাইভেট DNS বা শংসাপত্রের নাম যাচাইয়ের উপর নির্ভর করে তখন সার্ভিস হোস্টনেম ঠিক যেমন জারি হয়েছে তেমনই রাখুন। অন্য ব্যবহারকারীর সংরক্ষিত সংযোগ থেকে কপি করা হোস্ট ঠিকানা পুনরায় ব্যবহার করা এমন মেশিনে পৌঁছানোর দ্রুততম উপায় যা উত্তর দেয় কিন্তু পুরোনো ডেটাবেস ধরে রাখে।

রুট, অনুমোদিত রিসোর্স এবং নাম-সমাধান যিনি VPN চালান তার অধীন। একটি ডেটা-সোর্স ফর্ম এমন রুট ইনস্টল করতে পারে না যা টানেল প্রোফাইল কখনও পাঠায়নি, এবং এটি গেটওয়ে নীতি প্রশস্ত করতে পারে না। যখন হোস্ট রিজলভ হয় এবং পোর্ট উত্তর দেয়, সমস্যার নেটওয়ার্ক দিক শেষ।

অপারেটরের জারি করা প্রাইভেট এন্ডপয়েন্ট লিখুন

QGIS-এর PostgreSQL ফর্ম libpq যে ফিল্ডগুলো আশা করে তা প্রতিফলিত করে, তাই কমান্ড-লাইন সংযোগ যেভাবে করত সেভাবেই পূরণ করুন। সার্ভিস ও হোস্ট নেয় ডেটাবেস মেশিন, পোর্ট নেয় সেই লিসেনার যা সার্ভার আসলে খোলে, আর ডেটাবেস নেয় নির্দিষ্ট ক্যাটালগ, সার্ভারের ডিফল্ট নয়। পাসওয়ার্ড প্রকল্প ফাইলে নয়, একটি অথেনটিকেশন কনফিগারেশনে রাখুন, যাতে শেয়ার করা প্রকল্প কোনো ক্রেডেনশিয়াল বহন না করে।

কিছু টাইপ করার আগে দুটি নাম আলাদা করুন। গেটওয়ের নামের জায়গা VPN ক্লায়েন্টে এবং ডেটাবেসের নামের জায়গা QGIS-এ, আর তারা খুব কমই একই হোস্ট।

VPN gateway:   vpn.gis.lab.example       (profile only, not a data source)
Database host: db.gis.lab.example:5432   (PostGIS service)
Database name: gis_prod
TLS mode:      verify-full

যদি ডেটাবেস গেটওয়ের পিছনে অন্য মেশিনে থাকে, ফর্মে নামটি সেই মেশিনই হতে হবে। টানেলের ভেতর দিয়ে প্রাইভেট DNS-ই নামটি কাজ করায়, আর যে প্রকল্প কেবল সংযুক্ত থাকা অবস্থায় রিজলভ হয় সেটি খারাপ ক্যাশিং নয়, সঠিকভাবেই আচরণ করছে।

ডেটাবেসের TLS মোড টানেল থেকে আলাদা রাখুন

VPN পণ্যের নামে SSL টানেলকে বোঝায়, ডেটাবেস সেশনকে নয়। QGIS PostgreSQL SSL মোড libpq-তে পাঠায়, এবং সেই মোডই নিয়ন্ত্রণ করে ক্লায়েন্ট সার্ভার শংসাপত্র যাচাই করে কি না এবং তার ভেতরের হোস্টনেম পরীক্ষা করে কি না। verify-fullদুটোই করে, তাই শংসাপত্রে সার্ভিসের নাম থাকলে এই মোডই রাখার যোগ্য।

মোডটি disable-এ নামিয়ে আনা, কারণ টানেল ইতিমধ্যেই এনক্রিপ্টেড, সেই যাচাই সরিয়ে দেয় যে আপনি যে সার্ভারে পৌঁছেছেন সেটিই আপনি চেয়েছিলেন। যাচাই ব্যর্থ হলে সাধারণ কারণ নামের অমিল বা রুট শংসাপত্রের অনুপস্থিতি, আর দুটোই সংযোগ দুর্বল না করেই ঠিক করা যায়। sslrootcert-কে অপারেটরের প্রকাশ করা CA-এর দিকে নির্দেশ করুন এবং ফর্মের হোস্টনেম শংসাপত্রের নামের সঙ্গে অভিন্ন রাখুন.

প্রাইভেট রুটযুক্ত টানেল এবং বৈধ শংসাপত্রযুক্ত ডেটাবেসও রোলের কারণে ব্যর্থ হতে পারে। অ্যাপ্লিকেশন ক্রেডেনশিয়াল VPN ক্রেডেনশিয়াল থেকে আলাদা, এবং যে অ্যাকাউন্ট গেটওয়েতে প্রমাণিত হয় তার PostgreSQL-এ কোনো অন্তর্নিহিত অধিকার নেই।

প্রতিটি সীমা ক্রমে পরীক্ষা করুন এবং প্রথম ব্যর্থতা পড়ুন

ক্লায়েন্ট থেকে বাইরের দিকে নির্দিষ্ট ক্রমে কাজ করুন: নাম-সমাধান, TCP নাগাল, TLS, অথেনটিকেশন, তারপর কোয়েরি নিজেই। যে ধাপটি প্রথমে ব্যর্থ হয় সেটিই একমাত্র রিপোর্ট করার যোগ্য, আর লাফ দিয়ে এগোলে এমন সীমার ত্রুটি বার্তা আসে যেখানে আপনি এখনও পৌঁছাননি। চারটি কমান্ড প্রথম চারটি ধাপ ঢেকে দেয়।

getent hosts db.gis.lab.example
nc -vz db.gis.lab.example 5432
psql "host=db.gis.lab.example port=5432 dbname=gis_prod sslmode=verify-full" -c 'select 1'
curl -sS 'https://wms.gis.lab.example/ows?service=WMS&request=GetCapabilities' | head -c 200

getent থেকে খালি উত্তর মানে নাম-সমাধান সমস্যা, ডেটাবেস সমস্যা নয়। প্রত্যাখ্যাত বা সময়-শেষ nc মানে রুট বা firewall নিয়ম অনুপস্থিত, যা গেটওয়ে পক্ষের সংশোধন। psql থেকে TLS ত্রুটি মানে শংসাপত্র বা নাম ভুল, আর password authentication failed মানে আপনি PostgreSQL-এ পৌঁছেছেন এবং সমস্যা ক্রেডেনশিয়ালে। WMS লেয়ারের জন্য curl কলটি ক্যাপাবিলিটিজ XML ফেরত দেয় যা QGIS পার্স করত, তাই সেই আউটপুটে HTML লগইন পৃষ্ঠা খালি লেয়ারকে সঙ্গে সঙ্গে ব্যাখ্যা করে।

সময়-শেষের তুলনায় PostgreSQL ত্রুটি সুসংবাদ। এটি প্রমাণ করে গন্তব্য উত্তর দিয়েছে, যা টিকিটটিকে নেটওয়ার্ক দল থেকে ডেটাবেস বা GIS প্রশাসকের কাছে সরায়। প্রতিবেদনে এই পার্থক্য ধরে রাখলে একটি যাত্রা বাঁচে।

যখন প্রকল্প খালি লেয়ার নিয়ে খোলে

QGIS-এর ভেতরে কিছু পুনরায় লেখার আগে লেয়ারের সংরক্ষিত সোর্স দেখুন। লেয়ার বৈশিষ্ট্য প্রকল্পের সংরক্ষিত সঠিক সংযোগ স্ট্রিং দেখায়, আর পুরোনো হোস্টসহ নকল সংযোগ এন্ট্রি আগের অফিস নেটওয়ার্কের সাধারণ অবশিষ্ট। সংযোগ ঠিক করার পর প্রকল্প পুনরায় লোড করলে প্রোভাইডার সবসময় আবার পড়া হয় না, তাই লেয়ারটি সরিয়ে সংশোধিত সংযোগ থেকে আবার যোগ করুন।

তারপর নিশ্চিত করুন অথেনটিকেশন কনফিগারেশনটি লেয়ারের সঙ্গে সংযুক্তটিই, শুধু তালিকায় উপস্থিত নয়। ভিন্ন অথেনটিকেশন কনফিগ দিয়ে সংরক্ষিত লেয়ার ব্রাউজার প্যানেলে নীরবে ব্যর্থ হয়, অথচ স্বতন্ত্র psql পরীক্ষা পাস করে।

লেয়ার লোড হলে প্রকল্পটি ফাইলের জন্য কেবল আপেক্ষিক পথে সংরক্ষণ করুন এবং সার্ভিস সংযোগগুলি তাদের এন্ডপয়েন্টের নামে রাখুন। যে ব্যক্তি পরে প্রকল্পটি উত্তরাধিকারে পান তিনি টিকিট না খুলেই বলতে পারবেন কোন হোস্ট একটি ভাঙা লেয়ার আশা করেছিল।