OpenVPN 3 Python ભૂલ: સિસ્ટમના Python નહીં, સાધનને ઠીક કરો

VPN સંચાલનનો આદેશ શરૂ થાય ત્યારે ટ્રેસબેક દેખાય છે, અને પહેલી વૃત્તિ બીજું Python ઇન્સ્ટોલ કરવાની અથવા સિસ્ટમના ડિફૉલ્ટને બીજે ક્યાંક નિર્દેશ કરવાની હોય છે. એ વૃત્તિ એવા બે રનટાઇમને ભેગા કરે છે જેની એકબીજા સાથે કોઈ લેવાદેવા નથી. એક ઓપરેટિંગ સિસ્ટમ અને તેનાં પેકેજ કરેલાં સાધનોનું છે; બીજું તમે બનાવો છો તે કોઈપણ પ્રોજેક્ટનું છે. બીજાને સંતોષવા પહેલાને બદલવો એ જ રસ્તો છે જેના પર ચાલતું ડેસ્કટોપ પોતાનું પેકેજ મેનેજર ગુમાવે છે.

જે સરખામણી કરવા યોગ્ય છે તે ખરેખર નિષ્ફળ ગયેલા ઘટક અને જે રનટાઇમ બદલવાનો તમને અધિકાર છે તેની વચ્ચે છે. તે લગભગ ક્યારેય એક જ પદાર્થ હોતા નથી.

એક જેવા દેખાતા બે Python પ્રશ્નો

પહેલો પ્રશ્ન છે: કયા ઇન્ટરપ્રિટરે એ પ્રોગ્રામ ચલાવ્યો જેણે ટ્રેસબેક છાપ્યો? બીજો છે: મારા પ્રોજેક્ટે કયું ઇન્ટરપ્રિટર વાપરવું? ટર્મિનલમાં તે સરખા દેખાય છે, કારણ કે બંનેના જવાબ python3 લખીને આપવામાં આવે છે, અને તેમના માલિક અલગ, અપગ્રેડ માર્ગ અલગ અને અસરનો વ્યાપ અલગ છે.

સિસ્ટમ સાધન તેના ડિસ્ટ્રિબ્યુશન સાથે આવેલા ઇન્ટરપ્રિટર સાથે બંધાયેલું છે, તેમજ એ ઇન્ટરપ્રિટરના ABI સામે બનેલા કમ્પાઇલ થયેલા મોડ્યુલો સાથે. પ્રોજેક્ટ તમે તેના માટે બનાવો તે કોઈપણ એન્વાયર્નમેન્ટ સાથે બંધાયેલો છે. સિસ્ટમનું ડિફૉલ્ટ ખસેડવું મશીન પરનાં દરેક સાધન માટે પહેલાને એકસાથે બદલે છે; એન્વાયર્નમેન્ટ બનાવવું એક ડિરેક્ટરી માટે બીજાને બદલે છે.

એ ક્રિયાઓમાંથી ફક્ત એક જ એક મિનિટમાં પાછી ફેરવી શકાય છે. તે પહેલી નથી.

કયા ઘટકે ભૂલ પેદા કરી

બીજું કંઈ વાંચતા પહેલાં ટ્રેસબેકની પહેલી લાઇન અને તેને પેદા કરનારી એક્ઝિક્યુટેબલ ફાઇલ વાંચો. કમાન્ડ-લાઇન ફ્રન્ટએન્ડ, વિશેષાધિકાર પ્રાપ્ત સેવા અને API બાઇન્ડિંગ અલગ અલગ ટુકડા છે, અને તેમાંથી ફક્ત કેટલાક જ Python છે.

command -v openvpn3
head -n 1 "$(command -v openvpn3)"
dpkg -S "$(command -v openvpn3)" 2>/dev/null
systemctl status openvpn3-service-client --no-pager

સ્ક્રિપ્ટની પહેલી લાઇન જે ઇન્ટરપ્રિટર વાપરશે તેનું નામ આપે છે, અને ટ્રેસબેક એ જ ઇન્ટરપ્રિટરમાંથી આવ્યો છે. પેકેજ ક્વેરી તમને કહે છે કે ફાઇલ કોની છે, જે નક્કી કરે છે કે કોને તે બદલવાની પરવાનગી છે. સેવાની સ્થિતિ સાવ બીજા પ્રશ્નનો જવાબ આપે છે: જે વિશેષાધિકાર પ્રાપ્ત બેકએન્ડ ખરેખર સેશન સ્થાપે છે તે ચાલી રહ્યું છે કે નહીં.

મોડ્યુલ આયાત ભૂલ, D-Bus સક્રિયકરણનો ઇનકાર અને નકારાયેલ ક્રેડેન્શિયલ ત્રણ અલગ તબક્કા છે. આયાત ભૂલ કોઈ સેશન હોવા પહેલાં જ થાય છે, તેથી કોઈપણ VPN રૂપરેખાંકન તેને ઠીક કરશે નહીં, અને ચાલતી સેવા પણ તેને ઠીક કરશે નહીં. સંદેશને એ ત્રણ તબક્કામાંથી એકમાં વર્ગીકૃત કરવો એ ખરેખર પહેલું પગલું છે.

પ્રોજેક્ટ એન્વાયર્નમેન્ટ શું ઠીક કરી શકે અને શું નહીં

પ્રોજેક્ટ એન્વાયર્નમેન્ટ પ્રોજેક્ટની સમસ્યા ઉકેલે છે: એક એપ્લિકેશનને જરૂરી ચોક્કસ લાઇબ્રેરી આવૃત્તિઓ, બાકીના બધાથી અલગ. તે ખરેખર ઉપયોગી છે, અને જ્યારે નિષ્ફળ પ્રોગ્રામ તમારી પોતાની સ્ક્રિપ્ટ હોય ત્યારે તે યોગ્ય સાધન છે.

uv run --python 3.11 app.py
python3 -c 'import openvpn3; print(openvpn3.__file__)'

બીજો આદેશ દર્શાવે છે કે આપેલું ઇન્ટરપ્રિટર બાઇન્ડિંગની કઈ નકલ જોઈ શકે છે, જે ગુમ થયેલા પેકેજને છાયા પડેલા પેકેજથી અલગ પાડવાનો સૌથી ઝડપી રસ્તો છે. તેને નિષ્ફળ સ્ક્રિપ્ટ વાપરે તે ઇન્ટરપ્રિટર સાથે ચલાવો, આકસ્મિક રીતે કામ કરતા બીજા સાથે નહીં.

પ્રોજેક્ટ એન્વાયર્નમેન્ટ જે કરી શકતું નથી તે છે ડિસ્ટ્રિબ્યુશને પેકેજ કરેલા ફ્રન્ટએન્ડને ઠીક કરવો. એ પ્રોગ્રામની નિર્ભરતાઓ પેકેજ મેનેજરે પસંદ કરેલા ઇન્ટરપ્રિટર માટે બનેલી છે, અને તેને તમારા પ્રોજેક્ટના એન્વાયર્નમેન્ટમાં ચલાવવાથી કાં તો નિષ્ફળતા મળે છે અથવા એવું મિશ્રણ બને છે જેને કોઈ ટેકો આપતું નથી. એન્વાયર્નમેન્ટ વેરિયેબલ વડે તેમાં પાથ દાખલ કરવા એ વધારાના પગલાં સાથેની એ જ ભૂલ છે: સાધન શું લોડ કરે છે તે બદલ્યું, પણ જેની સામે તેની કસોટી થઈ હતી તે નહીં. એ બદલો બરાબર ત્યાં સુધી ઉકેલ જેવો લાગે છે જ્યાં સુધી આગલી આયાત ન આવે.

સિસ્ટમના ઇન્ટરપ્રિટરને ફરી નિર્દેશ કરવો છટકું કેમ છે

ડિફૉલ્ટ ઇન્ટરપ્રિટર બદલવું આકર્ષક છે કારણ કે તે એક આદેશમાં ટ્રેસબેક ઠીક કરતું લાગે છે. તે હોસ્ટ પરના દરેક પેકેજ કરેલા Python સાધન જે ધારણા પર બન્યાં છે તે પણ તોડે છે, અને નિષ્ફળતાઓ પછી અને અસંબંધિત જગ્યાએ દેખાય છે.

વૈકલ્પિક પસંદગીની પદ્ધતિઓ સમાન અમલીકરણો વચ્ચે બદલવા માટે બનાવાઈ હતી, જૂનાં કમ્પાઇલ થયેલા મોડ્યુલો નીચે નવી ભાષા ઇન્સ્ટોલ કરવા માટે નહીં. કમ્પાઇલ થયેલા એક્સ્ટેન્શન ચોક્કસ ABI માટે બનાવાય છે, તેથી ગઈકાલે આયાત થયેલું મોડ્યુલ આજે એક પણ પેકેજ દૂર કર્યા વિના લોડ થવામાં નિષ્ફળ જઈ શકે છે.

લોકોને મળતી સલાહમાં નામનું છટકું પણ છે. આવૃત્તિ વગરનો python આદેશ ડિસ્ટ્રિબ્યુશન અને એન્વાયર્નમેન્ટમાં એક સર્વવ્યાપી અર્થ ધરાવતો નથી, અને તેને ચોક્કસ મુખ્ય આવૃત્તિ માટે સ્થિર સમાનાર્થી તરીકે ગણવાથી એવા ઉકેલ મળે છે જે ફક્ત જ્યાં લખાયા ત્યાં જ કામ કરે છે. બ્લોગ પોસ્ટની નહીં, તમારી સામેની સિસ્ટમની નીતિ વાંચો.

અલગ સ્વીકૃતિ કસોટીઓ

અંતે બે કસોટીઓ હોવી જોઈએ, અને એક પાસ થવાથી બીજા વિશે કંઈ કહેવાતું નથી. પહેલી એ છે કે સમર્થિત ક્લાયન્ટ આદેશ જે ઇન્ટરપ્રિટર માટે પેકેજ થયો હતો તેની સાથે કામ કરે છે. બીજી એ છે કે વિશેષાધિકાર પ્રાપ્ત સેવા સેશન સ્થાપે છે અને ટનલ ટ્રાફિક વહન કરે છે.

openvpn3 sessions-list
openvpn3-service-client --help 2>/dev/null | head -n 3
ip -4 addr show tun0

કામ કરતી વખતે મશીન સુધીનો સ્વતંત્ર રસ્તો રાખો, ખાસ કરીને જો VPN તમારો એકમાત્ર વહીવટી પ્રવેશ વહન કરે છે. સિસ્ટમ ઇન્ટરપ્રિટરમાં ફેરફાર એ જ પ્રકારનું સંપાદન છે જે એ પ્રવેશ અડધે રસ્તે દૂર કરી શકે છે.

જો નિષ્ફળતા સિસ્ટમ સાધન માટે ગુમ થયેલું મોડ્યુલ હોય, તો સુધારો સમર્થિત કાર્યપ્રવાહ દ્વારા પેકેજ ક્રિયા છે. જો નિષ્ફળતા તમારા પોતાના પ્રોજેક્ટમાં આવૃત્તિ વિરોધાભાસ હોય, તો સુધારો એન્વાયર્નમેન્ટ છે. એ બે વચ્ચે પસંદગી એ આખો નિર્ણય છે, અને તે કયા પ્રોગ્રામે ટ્રેસબેક છાપ્યો તેના પર નક્કી થાય છે.