VPN रिपोजिटरी थपेपछि NO_PUBKEY सँग apt अद्यावधिक असफल हुन्छ

NO_PUBKEY र हराएको Release फाइल विश्वासका असफलता हुन्, सञ्जालका खराबी होइनन्। विक्रेताको कुञ्जी signed-by ले पिन गर्ने वा स्रोत हटाउने निर्णय गर्नुहोस्।

तपाईंको 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 प्रयोग गर्नुहोस्; त्यही म्यानुअलमा अभिलेख गरिएको व्यवस्था हो, र अद्यावधिक सहने पनि त्यही हो।

सम्बन्धित लेखहरू