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 संपूर्ण चक्र वाचवतो।

संबंधित लेख