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 आपकी एकमात्र प्रशासनिक पहुँच ले जाता है। सिस्टम इंटरप्रेटर में बदलाव ठीक उसी तरह का संपादन है जो वह पहुँच आधे रास्ते में हटा सकता है।

यदि विफलता किसी सिस्टम औज़ार के लिए गायब मॉड्यूल है, तो सुधार समर्थित कार्यप्रवाह के ज़रिए पैकेज क्रिया है। यदि विफलता आपके अपने प्रोजेक्ट में संस्करण टकराव है, तो सुधार वातावरण है। इन दोनों के बीच चुनाव ही पूरा निर्णय है, और यह इससे तय होता है कि किस प्रोग्राम ने ट्रेसबैक छापा।