तपाईंको Raspberry Pi का लागि पुरानो openfortivpn .deb उपयुक्त छ?

फोरमको उत्तरले तपाईंलाई पूरा फाइलनाम दिन्छ, र फाइलनाम समाधानजस्तो देखिन्छ: एउटा .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 पहिलो पुस्तकालय अद्यावधिकसम्म चल्छ, र त्यसपछि त्यही समस्या भएको कसैले त्यही फोरम थ्रेड फेरि भेट्टाउनेछ।

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