VPN వెనుక QGIS ను PostGIS తో కనెక్ట్ చేయండి: దశలవారీగా

QGIS తన డేటా ప్రొవైడర్లు చేరగల ఏ మార్గాన్నైనా చదువుతుంది, కాబట్టి నడుస్తున్న VPN అనేది సెటప్‌లో సగం మాత్రమే. టన్నెల్ డెస్క్‌టాప్‌కు ఒక మార్గాన్ని మరియు పేరు పరిష్కార విధానాన్ని ఇస్తుంది; ప్రాజెక్టుకు ఇంకా సేవా ఎండ్‌పాయింట్, ప్రొవైడర్ ప్రోటోకాల్ మరియు సేవ అంగీకరించే ఆధారాలు కావాలి. ఇవి మూడు వేర్వేరు ఫీల్డ్‌లు, VPN యొక్క పబ్లిక్ శ్రోతను డేటాబేస్ ఫీల్డ్‌లో టైప్ చేయడం వాటిలో ఏదీ కాదు. ఈ గైడ్ ఒక PostGIS లేయర్‌ను QGIS ఫారమ్ నుండి తిరిగి వచ్చిన వరుస వరకు అనుసరిస్తుంది మరియు ప్రతి దశ నిరూపించే సరిహద్దును పేర్కొంటుంది.

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 కాల్ QGIS విశ్లేషించే సామర్థ్యాల XML ను తిరిగి ఇస్తుంది, కాబట్టి ఆ అవుట్‌పుట్‌లో HTML లాగిన్ పేజీ ఖాళీ లేయర్‌ను వెంటనే వివరిస్తుంది.

సమయం ముగియడంతో పోలిస్తే PostgreSQL లోపం మంచి వార్త. గమ్యం ప్రతిస్పందించినట్లు నిరూపిస్తుంది, ఇది టికెట్‌ను నెట్‌వర్క్ బృందం నుండి డేటాబేస్ లేదా GIS నిర్వాహకుడి వద్దకు మారుస్తుంది. నివేదికలో ఆ భేదాన్ని ఉంచడం ఒక రౌండ్‌ను ఆదా చేస్తుంది.

ప్రాజెక్ట్ ఖాళీ లేయర్లతో తెరిచినప్పుడు

QGIS లోపల, ఏదైనా మళ్లీ నమోదు చేయడానికి ముందు లేయర్ సేవ్ చేసిన మూలాన్ని తనిఖీ చేయండి. లేయర్ లక్షణాలు ప్రాజెక్ట్ సేవ్ చేసిన ఖచ్చితమైన కనెక్షన్ స్ట్రింగ్‌ను చూపుతాయి, పాత హోస్ట్‌తో ఉన్న నకిలీ కనెక్షన్ ఎంట్రీ మునుపటి కార్యాలయ నెట్‌వర్క్ యొక్క సాధారణ మిగులు. కనెక్షన్ సరిచేసిన తర్వాత ప్రాజెక్ట్‌ను మళ్లీ లోడ్ చేయడం ఎప్పుడూ ప్రొవైడర్‌ను మళ్లీ చదవదు, కాబట్టి లేయర్‌ను తీసి సరిచేసిన కనెక్షన్ నుండి మళ్లీ జోడించండి.

తర్వాత ప్రామాణీకరణ కాన్ఫిగరేషన్ జాబితాలో ఉండటమే కాదు, లేయర్‌కు జోడించబడినదే అని నిర్ధారించుకోండి. వేరే ప్రామాణీకరణ కాన్ఫిగరేషన్‌తో సేవ్ చేసిన లేయర్ బ్రౌజర్ ప్యానెల్‌లో నిశ్శబ్దంగా విఫలమవుతుంది, స్వతంత్ర psql పరీక్ష ఉత్తీర్ణమవుతుంది.

లేయర్ లోడ్ అయినప్పుడు, ప్రాజెక్ట్‌ను ఫైళ్లకు మాత్రమే సాపేక్ష మార్గాలతో సేవ్ చేయండి మరియు సేవా కనెక్షన్లను వాటి ఎండ్‌పాయింట్ పేరుతో ఉంచండి. ప్రాజెక్టును వారసత్వంగా పొందే తదుపరి వ్యక్తి టికెట్ తెరవకుండానే విరిగిన లేయర్ ఏ హోస్ట్‌ను ఆశించిందో చెప్పగలరు.