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 પરીક્ષણ પાસ થાય છે.

જ્યારે સ્તર લોડ થાય, પ્રોજેક્ટને ફક્ત ફાઇલો માટે સાપેક્ષ માર્ગો સાથે સંગ્રહો અને સેવા જોડાણોને તેમના એન્ડપોઇન્ટ પ્રમાણે નામ આપી રાખો. પ્રોજેક્ટ વારસામાં મળનારી આગલી વ્યક્તિ ટિકિટ ખોલ્યા વિના કહી શકશે કે તૂટેલા સ્તરે કયા હોસ્ટની અપેક્ષા રાખી હતી.