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 छाप्यो भन्नेले निर्धारण गर्छ।