Git को gpg PATH मा जित्ने भएकाले OpenVPN इन्स्टल असफल हुन्छ

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

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 ले पूरै चक्र बचाउँछ।