क्या पुराना openfortivpn .deb आपके Raspberry Pi के लिए सही है?

फ़ोरम का एक उत्तर आपको पूरा फ़ाइलनाम देता है, और फ़ाइलनाम समाधान जैसा लगता है: एक .deb, एक कमांड, हो गया। वह स्ट्रिंग वास्तव में जो एन्कोड करती है वह है पैकेज संस्करण, एक CPU आर्किटेक्चर और वह डिस्ट्रिब्यूशन सूट जिसके विरुद्ध इसे उस दिन बनाया गया था जिस दिन किसी ने पोस्ट लिखा था। उन तीनों में से कोई भी आपकी मेज़ पर रखे बोर्ड का स्वतः वर्णन नहीं करता। पुराना डाउनलोड एक मशीन की स्थिति का स्नैपशॉट है, आपके लिए इंस्टॉलेशन योजना नहीं।

फ़ाइलनाम चुपचाप क्या पिन करता है

openfortivpn_1.17.0-1_armhf.deb जैसा नाम दाएँ से बाएँ पढ़ें। प्रत्यय वह आर्किटेक्चर है जिसके लिए बाइनरी कंपाइल किया गया था, मध्य फ़ील्ड अपस्ट्रीम और पैकेजिंग रिवीज़न है, और अंतर्निहित चौथा फ़ील्ड उस सूट की लाइब्रेरी समुच्चय है जिसमें इसे बनाया गया था।

64-बिट Raspberry Pi OS इंस्टॉल पर सिस्टम आर्किटेक्चर arm64 है, इसलिए dpkg -i आर्किटेक्चर बेमेल के कारण armhf पैकेज अस्वीकार करता है। जहाँ multiarch इंस्टॉल संभव बनाता है वहाँ भी, बाइनरी उस रिलीज़ के लाइब्रेरी संस्करणों की अपेक्षा करता है जिसके विरुद्ध इसे बनाया गया था, और नया बेस सिस्टम उन्हें अब प्रदान न करे। परिणाम एक इंस्टॉल किया गया पैकेज है जिसका निष्पादन योग्य फ़ाइल शुरू नहीं होती, और यही वह विफलता है जिसे लोग आमतौर पर क्लाइंट के ही खराब होने के रूप में गलत समझते हैं।

बोर्ड के ARM डिवाइस होने से ARM पैकेज उपयुक्त नहीं हो जाता। आर्किटेक्चर एक अक्ष है; रिलीज़ और ABI अन्य दो हैं, और वे स्वतंत्र रूप से विफल होते हैं।

डाउनलोड लिंक माँगने से पहले डिस्ट्रिब्यूशन से पूछें

हर अनुरक्षित चैनल आपको बता सकता है कि वह अभी क्या इंस्टॉल करेगा। कोई भी फ़ाइल स्थानांतरण विचारने से पहले लक्ष्य मशीन पर, उसके वास्तव में उपयोग किए जाने वाले रिपॉज़िटरी के साथ क्वेरी चलाएँ।

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

संस्करण और रिपॉज़िटरी नाम वाली उम्मीदवार पंक्ति का अर्थ है कि डिस्ट्रिब्यूशन के पास इस सिस्टम के लिए पहले से बिल्ड है। उम्मीदवार का न होना, या ऐसे सूट से उम्मीदवार आना जिसे आप उपयोग करने का इरादा नहीं रखते थे, आपके स्रोतों के बारे में जानकारी है, सॉफ़्टवेयर के कहीं होने के बारे में नहीं।

यदि मेटाडेटा रीफ़्रेश विफल हो, तो उस विफलता को पैकेज के प्रश्न से अलग रखें। नाम रिज़ॉल्यूशन, रिपॉज़िटरी ट्रांसपोर्ट, अनुपस्थित Release हस्ताक्षर और जीवन-अंत वाला सूट—सभी क्लाइंट के शामिल होने से पहले apt update तोड़ देते हैं। स्रोत ठीक करना VPN क्लाइंट चुनने से अलग कार्य है, और दोनों को मिलाना ही वह तरीका है जिससे लोग मौजूदा सिस्टम को पुरानी रिलीज़ की ओर इंगित कर देते हैं।

apt क्या सत्यापित करता है, और डाउनलोड की गई फ़ाइल क्या नहीं पाती

सामान्य इंस्टॉल हस्ताक्षर श्रृंखला का पालन करता है: संग्रह अपनी इंडेक्स पर हस्ताक्षर करता है, इंडेक्स प्रत्येक पैकेज के लिए हैश रखता है, और पैकेज को मेल खाना चाहिए। संग्रह प्रमाणीकरण संदर्भ उस श्रृंखला को प्रत्येक अलग फ़ाइल से जुड़े हस्ताक्षर की जाँच के विचार से अलग करता है।

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

पुराने निर्देश को चलता रखने के लिए हस्ताक्षर त्रुटियों को दबाना या TLS सत्यापन बंद करना प्रक्रिया का वह अकेला हिस्सा हटा देता है जो कुछ भी जाँच रहा था। इसके बजाय विफल हो रही जाँच को बहाल करें।

क्लाइंट इंस्टॉल करें, फिर कनेक्शन को अलग से डीबग करें

जब अनुरक्षित उम्मीदवार मौजूद हो, तो उसे सामान्य समीक्षित लेनदेन से इंस्टॉल करें और पैकेज मैनेजर को दर्ज करने दें कि उसने क्या किया।

यदि परिनियोजन को वास्तव में अपस्ट्रीम बिल्ड चाहिए, तो प्रोजेक्ट के वर्तमान बिल्ड निर्देशों का पालन करें और इसे ऐसे सॉफ़्टवेयर के रूप में लें जिसे अब आप अनुरक्षित करते हैं: डेवलपमेंट पैकेज, pkg-config, TLS लाइब्रेरी के हेडर और PPP डेमॉन वास्तविक निर्भरताएँ हैं, और वह हटाने की प्रक्रिया भी जो आपको बाद में चाहिए होगी।

इंस्टॉलेशन केवल स्थानीय सॉफ़्टवेयर चरण है। गेटवे को क्लाइंट का प्रोटोकॉल और प्रमाणीकरण प्रवाह स्वीकार करना होगा, क्लाइंट को गेटवे द्वारा प्रस्तुत प्रमाणपत्र पर भरोसा करना होगा, और टनल को कार्यशील PPP परत के साथ रूट और रिज़ॉल्वर का स्वामी चाहिए। पूर्ण पैकेज लेनदेन इस बारे में कुछ सिद्ध नहीं करता कि गेटवे खाता स्वीकार करता है या निजी रेंज पहुँच योग्य है। इंस्टॉलर दोबारा चलाने के बजाय हर परत को वहीं जाँचें जहाँ वह टूटती है।

पुराने फ़ाइलनाम को बदलने वाली योजना

पहले प्लेटफ़ॉर्म पहचान लिखें: OS रिलीज़, आर्किटेक्चर और प्रयुक्त स्रोत सूची। फिर पैकेज जिस अधिकृत स्थान से आता है उसका नाम दें—चाहे वह डिस्ट्रिब्यूशन रिपॉज़िटरी हो, पिन की गई कुंजी वाली विक्रेता रिपॉज़िटरी हो, या आपके द्वारा स्वयं कंपाइल और पैकेज किया गया बिल्ड हो।

अंत में अनुरक्षक और अपडेट पथ का नाम दें। जिस Pi पर ऐसा क्लाइंट चल रहा है जिसका कोई स्वामी नहीं, वह पहले लाइब्रेरी अपडेट तक चलेगा, और फिर उसी समस्या वाला कोई व्यक्ति फिर से वही फ़ोरम थ्रेड ढूँढ लेगा।

सुधारी गई मान्यता इतनी सरल है कि एक पंक्ति में कही जा सके: पुराना पैकेज इस बात का प्रमाण है कि क्लाइंट कभी बना और चला, इस बात का प्रमाण नहीं कि वह आज रात आपके बोर्ड पर इंस्टॉल होगा। तीनों अक्ष जाँचें, फिर ऐसा चैनल चुनें जिसे आप अपडेट करते रह सकें।