VPN रिपॉज़िटरी जोड़ने के बाद NO_PUBKEY के साथ apt अपडेट विफल होता है

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

पहले, विफलता को सही श्रेणी में रखें

विश्वास विफलता स्रोत फ़ाइल का नाम लेती है और या तो गुम कुंजी या अनुपस्थित Release फ़ाइल। परिवहन विफलता अलग दिखती है: TLS प्रमाणपत्र त्रुटियाँ, अस्वीकृत कनेक्शन, समय-सीमा समाप्ति, या CONNECT से इनकार करने वाला प्रॉक्सी। यही अंतर तय करता है कि आप कौन-सा लेख पढ़ रहे हैं, क्योंकि TLS को रोकने वाला या विक्रेता के होस्ट को अवरुद्ध करने वाला VPN परिवहन त्रुटियाँ पैदा करता है, हस्ताक्षर त्रुटियाँ नहीं।

चलाएँ sudo apt update अकेले और अंत पढ़ें, ऊपर के कैश परिणामों को अनदेखा करते हुए। महत्वपूर्ण पंक्ति /etc/apt/sources.list.d/ का नाम लेती है और बताती है कि कौन-सी फ़ाइल खोलनी है।

यदि विफलता सुरंग के उठने के बाद होती है, तो सुरंग बंद रखकर और DNS को सिस्टम रिज़ॉल्वर से हल करके परखें। जो स्रोत VPN के बिना काम करता है, वह रूटिंग या अवरोधन का प्रश्न है, और कोई भी कुंजी प्रबंधन उसे ठीक नहीं करेगा।

तीन प्रश्न जो मार्ग चुनते हैं

क्या आप अभी भी इस स्रोत से पैकेज इंस्टॉल या अपग्रेड करते हैं? यदि क्लाइंट सक्रिय उपयोग में है, तो विश्वास की मरम्मत करें। यदि आपने क्लाइंट एक बार इंस्टॉल किया और अब NetworkManager में सादा प्रोफ़ाइल आयात करते हैं, तो स्रोत अतिरिक्त बोझ है और उसे हटाना ही ईमानदार मरम्मत है।

दूसरा, क्या विक्रेता ऐसी कुंजी और फिंगरप्रिंट प्रकाशित करता है जिसे आप चैनल के बाहर सत्यापित कर सकें? तीसरा, इस होस्ट पर कुंजियाँ कौन प्रबंधित करता है: डिस्ट्रीब्यूशन या आप? जिस कुंजी से हस्ताक्षरित स्रोत को आप सत्यापित नहीं कर सकते, वह अपडेट प्राधिकार है जो आपको नहीं देना चाहिए।

पहले प्रश्न का ना उत्तर विश्लेषण समाप्त करता है। तीनों बिंदुओं पर हाँ उत्तर signed-by मरम्मत की ओर ले जाता है, जो एकमात्र व्यवस्था है जो काम भी करती है और लेखा-परीक्षण योग्य भी रहती है। दोनों मार्गों को मिलाना, स्रोत रखकर उसे ज़बरदस्ती पार कराना, वह एकमात्र विकल्प है जिसे स्पष्ट रूप से बाहर रखना उचित है।

क्यों trusted=yes मरम्मत जैसा लगता है और है नहीं

sources.list मैनुअल पृष्ठ इस पर सीधा है। Trusted विकल्प को yes पर सेट करना apt से कहता है कि स्रोत को तब भी स्वीकार करे जब प्रमाणीकरण विफल हो, जो उस रिपॉज़िटरी के लिए apt-secure बंद कर देता है। पृष्ठ इसे स्थानीय संदर्भ के लिए रखता है, यदि बिलकुल उपयोग हो।

यह विक्रेता पर भरोसे का संकीर्ण संस्करण नहीं है। यह इस प्रश्न को हटा देता है कि इंडेक्स पर किसने हस्ताक्षर किए, इसलिए जो भी उस होस्टनाम के लिए उत्तर दे सकता है, वह आपकी मशीन को root के रूप में इंस्टॉल होने वाले पैकेज दे सकता है।

मरम्मत का मार्ग: कुंजी लें, फिर उसे पिन करें

विक्रेता जिस स्थान का दस्तावेज़ीकरण करता है वहाँ से कुंजी लें और उसे एडमिनिस्ट्रेटर द्वारा प्रबंधित कीरिंग में डी-आर्मर करें, फिर रिपॉज़िटरी पंक्ति को उस फ़ाइल की ओर इंगित करें ताकि विश्वास सरक न सके।

1. विफल होने वाली पंक्ति पढ़कर कुंजी ID और स्रोत फ़ाइल का नाम लें।
2. विक्रेता की ASCII-आर्मर की हुई कुंजी डाउनलोड करें और gpg --dearmor को /etc/apt/keyrings/vendor-name.gpg में चलाएँ।
3. [signed-by=/etc/apt/keyrings/vendor-name.gpg] जोड़ें उस विक्रेता की .list फ़ाइल की प्रविष्टि में।
4. चलाएँ sudo apt update और पुष्टि करें कि स्रोत हस्ताक्षर चेतावनी दोहराने के बजाय इंडेक्स लाता है।

पैकेज के साथ आने वाली कुंजियों के लिए /usr/share/keyrings को प्राथमिकता दें और हाथ से रखी कुंजियों के लिए /etc/apt/keyrings। यह विभाजन सौंदर्य नहीं है: यह अगले एडमिनिस्ट्रेटर को बताता है कि कौन-सी कुंजियाँ पैकेज अपग्रेड के बाद टिकेंगी और किन्हें मनुष्य की आवश्यकता है।

भरोसा करने से पहले फिंगरप्रिंट को विक्रेता के प्रकाशित मान से मिलाएँ। फ़ोरम पोस्ट से चिपकाई गई कुंजी ID वह तरीका है जिससे मशीन ऐसे अपडेट प्राधिकार पर भरोसा करने लगती है जिसका नाम कोई नहीं बता सकता।

हटाने का मार्ग, और त्रुटि क्यों लौट सकती है

देखें कि इंस्टॉलर ने वास्तव में क्या लिखा, क्योंकि कई फ़ाइलें एक ही विक्रेता का उल्लेख कर सकती हैं और उनमें से एक आमतौर पर बची हुई प्रति होती है।

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt उस निर्देशिका से केवल .list और .sources फ़ाइलें पढ़ता है, इसलिए .save या .distUpgrade प्रति पहले से अनदेखी है; फिर भी उसे हटाना किसी बाद के पाठक को उसे गलती से बहाल करने से रोकता है। स्रोत हटाने से कुछ अनइंस्टॉल नहीं होता, और apt तब इंस्टॉल किए गए VPN पैकेज को स्थानीय रूप से इंस्टॉल या अब उपलब्ध न होना बता सकता है, जो पैकेज-स्थिति संदेश है, विश्वास त्रुटि का लौटना नहीं।

बार-बार आने वाला मामला पुराना निर्देश है जो कुंजियों को apt-key से वैश्विक विश्वस्त रिंग में इंस्टॉल करता था। वह मार्ग बहिष्कृत है, और रिलीज़ अपग्रेड कुंजी को गिरा हुआ या केवल बिना परामर्श वाला छोड़ सकता है, और ठीक इसी कारण एक वर्ष तक शांत रही त्रुटि उस सप्ताह दिखती है जब आप अपग्रेड करते हैं। /etc/apt/trusted.gpg.d/ जाँचें, फिर विश्वास का निर्णय रिपॉज़िटरी पंक्ति में ले जाएँ जहाँ उसका स्थान है। यदि विक्रेता अभी भी apt-key निर्देश छापता है, तो भी signed-by उपयोग करें; यही वह व्यवस्था है जिसका मैनुअल दस्तावेज़ीकरण करता है, और यही अपग्रेड के बाद टिकती है।