OpenVPN 3 Python பிழை: கருவியைச் சரிசெய்யுங்கள், கணினி Python அல்ல

VPN மேலாண்மை கட்டளை தொடங்கும்போது Traceback தோன்றும், முதல் உணர்வு வேறு Python-ஐ நிறுவுவதற்கோ கணினியின் இயல்புநிலையை வேறெங்கோ திருப்புவதற்கோ ஓடும். அந்த உணர்வு ஒன்றுக்கொன்று தொடர்பில்லாத இரண்டு runtime-களைக் கலக்கிறது. ஒன்று இயக்க முறைமைக்கும் அதன் தொகுக்கப்பட்ட கருவிகளுக்கும் சொந்தம்; மற்றொன்று நீங்கள் கட்டும் எந்த திட்டத்திற்கும் சொந்தம். இரண்டாவதை திருப்திப்படுத்த முதல் ஒன்றை மாற்றுவதே இயங்கும் desktop தன் package manager-ஐ இழக்கும் வழி.

செய்யத் தகுந்த ஒப்பீடு, உண்மையில் தோல்வியுற்ற கூறுக்கும் நீங்கள் மாற்ற அதிகாரம் பெற்ற runtime-க்கும் இடையிலானது. அவை எப்போதும் ஒரே பொருளாக இருப்பதில்லை.

ஒன்று போலத் தோன்றும் இரண்டு Python கேள்விகள்

முதல் கேள்வி: Traceback-ஐ அச்சிட்ட நிரலை எந்த interpreter இயக்கியது? இரண்டாவது: எனது திட்டம் எந்த interpreter-ஐ பயன்படுத்த வேண்டும்? முனையத்தில் இரண்டும் ஒரே மாதிரி தெரிகின்றன, ஏனெனில் இரண்டிற்கும் python3 தட்டச்சு செய்து பதில் கிடைக்கிறது, ஆனால் அவற்றுக்கு வெவ்வேறு உரிமையாளர்கள், வெவ்வேறு மேம்பாட்டுப் பாதைகள், வெவ்வேறு தாக்க வீச்சு உள்ளன.

கணினி கருவி ஒன்று அதன் distribution வழங்கிய interpreter-உடனும், அந்த interpreter-இன் ABI-க்கு எதிராக கட்டப்பட்ட compile செய்யப்பட்ட module-களுடனும் பிணைக்கப்பட்டுள்ளது. திட்டம் ஒன்று நீங்கள் அதற்காக உருவாக்கும் எந்த சூழலுடனும் பிணைக்கப்பட்டுள்ளது. கணினி இயல்புநிலையை நகர்த்துவது முதல் ஒன்றை இயந்திரத்தின் ஒவ்வொரு கருவிக்கும் ஒரே நேரத்தில் மாற்றும்; சூழலை உருவாக்குவது இரண்டாவதை ஒரு கோப்பகத்திற்கு மட்டும் மாற்றும்.

அந்தச் செயல்களில் ஒன்றை மட்டுமே ஒரு நிமிடத்தில் மீளச் செய்ய முடியும். அது முதல் ஒன்று அல்ல.

பிழையை உருவாக்கிய கூறு எது

வேறு எதையும் படிப்பதற்கு முன் Traceback-இன் முதல் வரியையும் அதை உருவாக்கிய இயக்கக் கோப்பையும் படியுங்கள். கட்டளை வரி frontend, சிறப்பு அனுமதி சேவை, 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

script-இன் முதல் வரி அது பயன்படுத்தும் interpreter-ஐக் குறிப்பிடுகிறது, Traceback அந்த interpreter-இலிருந்தே வந்தது. தொகுப்பு வினவல் கோப்பு யாருக்குச் சொந்தம் என்று சொல்கிறது, அது யார் அதை மாற்றலாம் என்பதைத் தீர்மானிக்கிறது. சேவையின் நிலை முற்றிலும் வேறு கேள்விக்கு பதிலளிக்கிறது: உண்மையில் அமர்வுகளைத் திறக்கும் சிறப்பு அனுமதி backend இயங்குகிறதா என்பது.

module இறக்குமதி பிழை, D-Bus செயல்படுத்தல் மறுப்பு மற்றும் நிராகரிக்கப்பட்ட சான்றுகள் ஆகியவை மூன்று வெவ்வேறு நிலைகள். இறக்குமதி பிழை எந்த அமர்வும் இருப்பதற்கு முன்பே நிகழ்கிறது, எனவே எவ்வளவு VPN உள்ளமைவும் அதைச் சரிசெய்யாது, இயங்கும் சேவையும் அதைச் சரிசெய்யாது. செய்தியை அந்த மூன்று நிலைகளில் ஒன்றில் வகைப்படுத்துவதே உண்மையான முதல் படி.

திட்டச் சூழல் எதைச் சரிசெய்ய முடியும், எதை முடியாது

திட்டச் சூழல் ஒரு திட்டச் சிக்கலைத் தீர்க்கிறது: ஒரு பயன்பாட்டிற்குத் தேவையான சரியான நூலக பதிப்புகளை, மற்ற அனைத்திலிருந்தும் தனிமைப்படுத்தி. அது உண்மையிலேயே பயனுள்ளது, தோல்வியுறும் நிரல் உங்கள் சொந்த script ஆக இருந்தால் அதுவே சரியான கருவி.

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

இரண்டாவது கட்டளை ஒரு குறிப்பிட்ட interpreter எந்த இணைப்பு நகலைப் பார்க்க முடியும் என்பதைக் காட்டுகிறது, காணாமல் போன தொகுப்பை மறைக்கப்பட்ட தொகுப்பிலிருந்து வேறுபடுத்த இதுவே விரைவான வழி. தோல்வியுறும் script பயன்படுத்தும் interpreter-உடன் அதை இயக்குங்கள், தற்செயலாக வேலை செய்யும் வேறொன்றுடன் அல்ல.

திட்டச் சூழல் செய்ய முடியாதது distribution தொகுத்த frontend-ஐ சரிசெய்வது. அந்த நிரலின் சார்புகள் package manager தேர்ந்தெடுத்த interpreter-க்காகக் கட்டப்பட்டவை, அதை உங்கள் திட்டச் சூழலுக்குள் இயக்குவது ஒன்று தோல்வியடையும் அல்லது யாரும் ஆதரிக்காத கலவையை உருவாக்கும். சூழல் மாறியின் மூலம் அதில் பாதைகளைச் செலுத்துவது கூடுதல் படிகள் கொண்ட அதே தவறு: கருவி எதை ஏற்றுகிறது என்பதை மாற்றினீர்கள், ஆனால் அது எதற்கு எதிராகச் சோதிக்கப்பட்டது என்பதை மாற்றவில்லை. அந்தப் பரிமாற்றம் அடுத்த இறக்குமதி வரும் வரை மட்டுமே சரிசெய்தல் போலத் தெரிகிறது.

கணினி interpreter-ஐத் திருப்புவது பொறி ஏன்

இயல்புநிலை interpreter-ஐ மாற்றுவது கவர்ச்சிகரமானது, ஏனெனில் அது ஒரே கட்டளையில் Traceback-ஐ சரிசெய்வது போலத் தெரிகிறது. அது host-இல் உள்ள ஒவ்வொரு தொகுக்கப்பட்ட Python கருவியும் அடிப்படையாகக் கொண்ட அனுமானத்தையும் உடைக்கிறது, தோல்விகள் பின்னர் தொடர்பில்லாத இடங்களில் தோன்றும்.

மாற்றுத் தேர்வு முறைகள் சமமான செயலாக்கங்களுக்கு இடையே மாறுவதற்காக வடிவமைக்கப்பட்டவை, பழைய compile செய்யப்பட்ட module-களின் கீழ் புதிய மொழியை நிறுவுவதற்கு அல்ல. Compile செய்யப்பட்ட நீட்டிப்புகள் குறிப்பிட்ட ABI-க்காகக் கட்டப்படுகின்றன, எனவே நேற்று இறக்குமதியான module ஒன்றும் அகற்றப்படாமல் இன்று ஏற்ற முடியாமல் போகலாம்.

மக்கள் காணும் ஆலோசனைகளில் பெயர் சார்ந்த பொறியும் உள்ளது. பதிப்பு இல்லாத python கட்டளைக்கு distribution-கள் மற்றும் சூழல்களுக்கு இடையே ஒரே பொதுவான பொருள் இல்லை, அதை ஒரு குறிப்பிட்ட முதன்மை பதிப்பின் நிலையான ஒத்தசொல்லாகக் கருதுவது அது எழுதப்பட்ட இயந்திரத்தில் மட்டுமே வேலை செய்யும் திருத்தங்களைத் தரும். blog இடுகையில் உள்ள கொள்கையை அல்ல, உங்கள் முன் உள்ள கணினியின் கொள்கையைப் படியுங்கள்.

தனித்த ஏற்புச் சோதனைகள்

இறுதியில் இரண்டு சோதனைகள் இருக்க வேண்டும், ஒன்றைக் கடப்பது மற்றொன்றைப் பற்றி எதையும் சொல்லாது. முதலாவது, ஆதரிக்கப்படும் client கட்டளை அது தொகுக்கப்பட்ட interpreter-உடன் வேலை செய்வது. இரண்டாவது, சிறப்பு அனுமதி சேவை ஒரு அமர்வை நிறுவுவதும் tunnel போக்குவரத்தை எடுத்துச் செல்வதும்.

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

வேலை செய்யும்போது இயந்திரத்திற்குள் செல்ல ஒரு சுயாதீன வழியை வைத்திருங்கள், குறிப்பாக VPN உங்கள் ஒரே நிர்வாக அணுகலை எடுத்துச் சென்றால். கணினி interpreter-இல் ஒரு மாற்றம் என்பது அந்த அணுகலைப் பாதியில் பறிக்கக்கூடிய திருத்தம் தான்.

தோல்வி ஒரு கணினி கருவிக்கான காணாமல் போன module ஆக இருந்தால், திருத்தம் ஆதரிக்கப்படும் பணிப்பாய்வு வழியாக ஒரு தொகுப்புச் செயல்பாடு. தோல்வி உங்கள் சொந்த திட்டத்தில் பதிப்பு முரண்பாடாக இருந்தால், திருத்தம் ஒரு சூழல். அவற்றுக்கு இடையே தேர்ந்தெடுப்பதே முழு முடிவு, அது Traceback-ஐ எந்த நிரல் அச்சிட்டது என்பதால் தீர்மானிக்கப்படுகிறது.