OpenVPN 3 Python त्रुटी: साधन दुरुस्त करा, सिस्टमचे Python नाही

VPN व्यवस्थापन आदेश सुरू होताच Traceback दिसते, आणि पहिली प्रवृत्ती दुसरे Python स्थापित करण्याकडे किंवा सिस्टमचे डीफॉल्ट दुसरीकडे वळवण्याकडे धाव घेते। ती प्रवृत्ती परस्परांशी काहीही संबंध नसलेल्या दोन रनटाइम्सना मिसळते। एक ऑपरेटिंग सिस्टम आणि त्याच्या पॅकेज केलेल्या साधनांचे आहे; दुसरे तुम्ही बनवत असलेल्या कोणत्याही प्रकल्पाचे आहे। दुसऱ्याला तृप्त करण्यासाठी पहिले बदलणे म्हणजे कार्यरत डेस्कटॉप आपला पॅकेज व्यवस्थापक गमावण्याचा मार्ग।

करण्यासारखी तुलना म्हणजे प्रत्यक्षात अपयशी ठरलेला घटक आणि तुम्हाला बदलण्याचा अधिकार असलेला रनटाइम यांच्यातील। ते जवळजवळ कधीच एकच वस्तू नसतात।

एकासारखे वाटणारे दोन Python प्रश्न

पहिला प्रश्न: Traceback छापणारा कार्यक्रम कोणत्या इंटरप्रिटरने चालवला? दुसरा: माझ्या प्रकल्पाने कोणता इंटरप्रिटर वापरावा? टर्मिनलमध्ये दोन्ही सारखे दिसतात, कारण दोन्हींना python3 टाइप करून उत्तर मिळते, पण त्यांचे मालक, अपग्रेड मार्ग आणि परिणामाची व्याप्ती वेगळी आहे।

सिस्टम साधन आपल्या डिस्ट्रिब्युशनने दिलेल्या इंटरप्रिटरशी आणि त्या इंटरप्रिटरच्या ABI विरुद्ध बांधलेल्या संकलित मॉड्यूलशी बांधलेले असते। प्रकल्प तुम्ही त्यासाठी तयार करता त्या कोणत्याही वातावरणाशी बांधलेला असतो। सिस्टम डीफॉल्ट हलवल्यास पहिले यंत्रावरील प्रत्येक साधनासाठी एकाच वेळी बदलते; वातावरण तयार केल्यास दुसरे एका डिरेक्टरीसाठी बदलते।

त्या क्रियांपैकी फक्त एकच एका मिनिटात पूर्ववत करता येते। ती पहिली नाही।

त्रुटी कोणत्या घटकाने निर्माण केली

इतर काहीही वाचण्यापूर्वी Traceback ची पहिली ओळ आणि ती निर्माण करणारी एक्झिक्युटेबल वाचा। कमांड-लाइन फ्रंटएंड, विशेषाधिकारित सेवा आणि 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

स्क्रिप्टची पहिली ओळ ती वापरणार असलेल्या इंटरप्रिटरचे नाव सांगते, आणि Traceback त्या इंटरप्रिटरकडूनच आले आहे। पॅकेजची चौकशी फाइल कोणाची आहे ते सांगते, ज्यावरून कोणाला ती बदलण्याची परवानगी आहे हे ठरते। सेवेची स्थिती पूर्णपणे वेगळ्या प्रश्नाचे उत्तर देते: प्रत्यक्षात सत्रे उघडणारा विशेषाधिकारित बॅकएंड चालू आहे का।

मॉड्यूल आयात त्रुटी, D-Bus सक्रियतेचा नकार आणि नाकारलेली ओळखपत्रे या तीन वेगवेगळ्या टप्प्या आहेत। आयात त्रुटी कोणतेही सत्र अस्तित्वात येण्यापूर्वीच होते, त्यामुळे कितीही VPN संरचना ती दुरुस्त करणार नाही, आणि कार्यरत सेवाही ती दुरुस्त करणार नाही। संदेशाचे वर्गीकरण या तीन टप्प्यांपैकी एकात करणे हेच खरे पहिले पाऊल आहे।

प्रकल्प वातावरण काय दुरुस्त करू शकते आणि काय नाही

प्रकल्प वातावरण प्रकल्पाची समस्या सोडवते: एका अनुप्रयोगाला लागणाऱ्या नेमक्या ग्रंथालय आवृत्त्या, बाकी सर्वांपासून वेगळ्या। ते खरोखर उपयुक्त आहे, आणि अपयशी होणारा कार्यक्रम तुमची स्वतःची स्क्रिप्ट असेल तेव्हा तेच योग्य साधन आहे।

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

दुसरा आदेश दिलेल्या इंटरप्रिटरला बाइंडिंग्जची कोणती प्रत दिसते ते दाखवतो, आणि गहाळ पॅकेजला झाकलेल्या पॅकेजपासून वेगळे ओळखण्याचा तो सर्वात वेगवान मार्ग आहे। अपयशी होणारी स्क्रिप्ट वापरते त्या इंटरप्रिटरने तो चालवा, योगायोगाने चालणाऱ्या दुसऱ्याने नाही।

प्रकल्प वातावरण जे करू शकत नाही ते म्हणजे डिस्ट्रिब्युशनने पॅकेज केलेला फ्रंटएंड दुरुस्त करणे। त्या कार्यक्रमाची अवलंबित्वे पॅकेज व्यवस्थापकाने निवडलेल्या इंटरप्रिटरसाठी बांधलेली आहेत, आणि तो तुमच्या प्रकल्पाच्या वातावरणात चालवल्यास एकतर अपयशी होतो किंवा कोणीही आधार देत नसलेले मिश्रण तयार होते। वातावरण चलाद्वारे त्यात मार्ग घुसवणे म्हणजे अधिक पायऱ्यांसह तीच चूक: साधन काय लोड करते ते बदलले, पण त्याची कशाविरुद्ध चाचणी झाली होती ते बदलले नाही। तो अदलाबदल पुढील आयातीपर्यंतच दुरुस्ती वाटतो।

सिस्टम इंटरप्रिटर वळवणे सापळा का आहे

डीफॉल्ट इंटरप्रिटर बदलणे आकर्षक वाटते कारण एका आदेशाने Traceback दुरुस्त होतो असे दिसते। ते होस्टवरील प्रत्येक पॅकेज केलेल्या Python साधनाची पायाभूत गृहीतकेही मोडते, आणि अपयशे नंतर असंबंधित ठिकाणी दिसतात।

पर्याय-निवड यंत्रणा समतुल्य अमलबजावणींमध्ये बदलण्यासाठी बनवल्या आहेत, जुन्या संकलित मॉड्यूलखाली नवीन भाषा बसवण्यासाठी नाही। संकलित विस्तार विशिष्ट ABI साठी बांधले जातात, त्यामुळे काल आयात झालेले मॉड्यूल आज एकही पॅकेज न काढता लोड होऊ शकत नाही।

लोकांना सापडणाऱ्या सल्ल्यांमध्ये नावाचा सापळाही आहे। आवृत्ती-रहित python आदेशाला डिस्ट्रिब्युशन आणि वातावरणांमध्ये एक सार्वत्रिक अर्थ नाही, आणि त्याला विशिष्ट प्रमुख आवृत्तीचा स्थिर समानार्थी मानल्यास जिथे लिहिला गेला त्या यंत्रावरच चालणाऱ्या दुरुस्त्या मिळतात। ब्लॉग पोस्टमधील धोरण नव्हे, तुमच्यासमोरच्या सिस्टमचे धोरण वाचा।

स्वतंत्र स्वीकृती चाचण्या

शेवटी दोन चाचण्या असाव्यात, आणि एक पास झाल्याने दुसऱ्याबद्दल काहीही सांगता येत नाही। पहिली म्हणजे समर्थित क्लायंट आदेश ज्या इंटरप्रिटरसाठी पॅकेज केला होता त्याच्यासह चालतो। दुसरी म्हणजे विशेषाधिकारित सेवा सत्र स्थापित करते आणि टनेल रहदारी वाहून नेते।

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

काम करताना यंत्रावर जाण्याचा स्वतंत्र मार्ग ठेवा, विशेषतः VPN तुमचा एकमेव प्रशासकीय प्रवेश वाहून नेत असेल तर। सिस्टम इंटरप्रिटरमधील बदल हाच असा संपादन आहे जो तो प्रवेश अर्ध्यात काढून टाकू शकतो।

अपयश सिस्टम साधनासाठी गहाळ मॉड्यूल असेल, तर दुरुस्ती समर्थित कार्यप्रवाहातून केलेली पॅकेज क्रिया आहे। अपयश तुमच्या स्वतःच्या प्रकल्पातील आवृत्ती-संघर्ष असेल, तर दुरुस्ती वातावरण आहे। या दोन्हींमधून निवडणे हाच संपूर्ण निर्णय आहे, आणि तो कोणत्या कार्यक्रमाने Traceback छापले यावर ठरतो।