OpenVPN इंस्टॉल विफल होता है क्योंकि Git का gpg PATH पर जीत जाता है

Chocolatey के अंतर्गत हस्ताक्षर या कुंजी त्रुटि के साथ मरने वाला OpenVPN इंस्टॉल आम तौर पर डाउनलोड की समस्या नहीं है। पैकेज एक सत्यापन चरण चलाता है जो gpg को कॉल करता है, और Windows उस नंगे नाम को PATH के माध्यम से हल करता है। अगर Git for Windows पहले इंस्टॉल हुआ था, तो उसका साथ आने वाला gpg.exe उस GnuPG बिल्ड से पहले बैठता है जिसकी OpenVPN अपेक्षा करता है, और गलत प्रोग्राम कॉल का जवाब देता है। आप जो त्रुटि देखते हैं वह वही है जिसके बारे में उस दूसरे प्रोग्राम ने शिकायत करने का फैसला किया, इसलिए वह कभी असली कारण नहीं बताती।

PATH का क्रम तय करता है कौन-सा gpg चलेगा

Windows के पास निष्पादन योग्य नामों का कोई केंद्रीय रजिस्टर नहीं है। जब कोई प्रक्रिया पूर्ण पथ के बिना gpg मांगती है, तो लोडर PATH की प्रविष्टियों को क्रम से देखता है और पहला मेल चलाता है। Git for Windows हस्ताक्षरित कमिट के काम करने के लिए अपनी usr/bin निर्देशिका के भीतर एक न्यूनतम GnuPG बिल्ड लाता है, और उसका इंस्टॉलर आम तौर पर उस निर्देशिका को उपयोगकर्ता के PATH के आरंभ के निकट रखता है।

GnuPG अपनी निर्देशिका में इंस्टॉल होता है, आम तौर पर C:\Program Files (x86)\GNU\GnuPG\pub, और वह प्रविष्टि सूची में बाद में हो सकती है या उपयोगकर्ता के PATH से पूरी तरह गायब हो सकती है। दोनों प्रोग्राम एक नाम और कमांड-लाइन इंटरफ़ेस का बड़ा हिस्सा साझा करते हैं, लेकिन अपनी स्थिति नहीं: Git बिल्ड कुंजी-रिंग कहीं और खोजता है, भिन्न संस्करण हो सकता है, और इंस्टॉलर द्वारा भेजे गए विकल्प स्वीकार न करे। वह असंगति हस्ताक्षर या कुंजी त्रुटि के रूप में सामने आती है, जो गलत बाइनरी ने जो देखा उसकी सच्ची रिपोर्ट है। संदेश में कुछ भी लोडर की ओर इशारा नहीं करता, क्योंकि लोडर ने ठीक वही किया जो उसे कहा गया था।

आप जिस शेल से शुरू करते हैं वह परिणाम क्यों तय करता है

विरासत का नियम वह हिस्सा है जिसे आत्मसात करना उचित है। चाइल्ड प्रक्रिया को उस शेल का वातावरण मिलता है जिसने उसे लॉन्च किया, इसलिए जो क्रम मायने रखता है वह Chocolatey के शुरू होने के क्षण का क्रम है, आपके सुधारने के बाद का क्रम नहीं।

इसलिए सेटिंग्स विंडो में PATH संपादित करके उसी टर्मिनल में इंस्टॉल फिर चलाने से अक्सर कुछ नहीं बदलता: टर्मिनल ने पुराना वातावरण रख लिया था। किसी भी बदलाव के बाद नया शेल शुरू करें, और फिर कोशिश करने से पहले उस नए शेल में where.exe gpg से पुष्टि करें। यही कारण है कि मशीन-स्तरीय प्रविष्टि उपयोगकर्ता-स्तरीय बदलाव को हरा सकती है, क्योंकि कुछ इंस्टॉलर मशीन के PATH के आरंभ में जोड़ते हैं और मशीन प्रविष्टियाँ उपयोगकर्ता प्रविष्टियों से पहले मूल्यांकित होती हैं। अगर दोनों स्तरों में GnuPG पथ है, तो तय करें कि आप वास्तव में किसे बनाए रख रहे हैं।

पहला सुधार: प्रविष्टियों का क्रम बदलें

सटीक सुधार यह है कि इच्छित GnuPG निर्देशिका जीते। उपयोगकर्ता के वातावरण चर खोलें, Path संपादित करें, और GnuPG की pub निर्देशिका को Git प्रविष्टियों के ऊपर ले जाएँ। फिर नई PowerShell विंडो खोलें, क्योंकि चल रही विंडो अभी भी पुरानी सूची रखे हुए है।

विकल्प इंस्टॉल के लिए अस्थायी स्वच्छ वातावरण है: Git प्रविष्टियाँ हटाएँ, नया शेल खोलें, choco install openvpn चलाएँ, फिर उन्हें बहाल करें।

दोनों दृष्टिकोण एक ही कारण से काम करते हैं, और दूसरा केवल तभी सुरक्षित है जब आप प्रविष्टियाँ वास्तव में बहाल करें। Git की usr/bin को PATH से हटाना हस्ताक्षरित कमिट को स्थायी रूप से तोड़ देता है, और काम करते gpg की अपेक्षा करने वाला अगला उपकरण अपने संदेश के साथ विफल होता है जिसका OpenVPN से कोई लेना-देना नहीं है। अगर आप अस्थायी मार्ग लेते हैं, तो टिकट में Path का मूल मान रखें ताकि बहाली पुनर्निर्माण नहीं, पेस्ट हो। प्रविष्टियों को क्रम में रखना टिकाऊ सुधार है; उन्हें हटाना समय-सीमा वाला अस्थायी उपाय है।

सत्यापित करें, फिर वापस रखें

Chocolatey जिस उपयोगकर्ता संदर्भ का उपयोग करेगा, उसी संदर्भ में पहले और बाद में सत्यापित करें। where.exe gpg हर मेल को समाधान क्रम में सूचीबद्ध करता है, इसलिए पहली पंक्ति वही है जो चलेगी; Get-Command gpg -All PowerShell में अधिक विवरण के साथ वही उत्तर देता है। फिर gpg --version पुष्टि करता है कि कौन-सा बिल्ड जवाब दिया।

अगर where.exe अभी भी Git की प्रति को पहले सूचीबद्ध करता है, तो क्रम-परिवर्तन उस सत्र तक नहीं पहुँचा, और कितनी भी बार पुनः इंस्टॉल करने से मदद नहीं मिलेगी। मशीन और उपयोगकर्ता दोनों के PATH को [Environment]::GetEnvironmentVariable('Path','Machine') से और 'User' के साथ वही कॉल जाँचें, क्योंकि प्रभावी सूची दोनों से बनती है। सफल इंस्टॉल के बाद, openvpn --version से फिर जाँचें और सेवा या GUI को एक बार शुरू करें, क्योंकि पैकेज साफ़ इंस्टॉल होकर भी ऐसी सेवा छोड़ सकता है जो शुरू नहीं होगी।

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

पैकेज का अपना लॉग पढ़ें कुछ और बदलने से पहले। C:\ProgramData\chocolatey\logs\chocolatey.log वह कमांड लाइन दर्ज करता है जो विफल हुई और वह निर्देशिका जहाँ से वह चली, जो आपको बताता है कि विफल कॉल हस्ताक्षर जाँच, निष्कर्षण या इंस्टॉल-पश्चात स्क्रिप्ट थी। यही अंतर तय करता है कि आप अभी भी gpg को डीबग कर रहे हैं या नहीं।

पुनरावृत्ति रोकने वाली आदत यह है कि PATH को प्रलेखित क्रम वाली साझा स्थिति मानें, निर्देशिकाओं का थैला नहीं। जब आप कोई ऐसा उपकरण इंस्टॉल करें जो सामान्य बाइनरी नाम लाता है, तो जाँचें कि आपके द्वारा खोले जाने वाले अगले शेल में वह किसे छाया में डालता है। फिर जिस क्रम पर आप टिके वह लिख लें, क्योंकि अगला इंस्टॉलर उसमें जोड़ेगा और अगला व्यक्ति सोचेगा कि जिस मशीन पर कुछ नहीं बदला वहाँ हस्ताक्षर जाँच क्यों विफल होती है। इंस्टॉल से पहले एक where.exe पूरा चक्र बचा लेता है।