तुमच्या 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 पहिल्या लायब्ररी अपडेटपर्यंत चालेल, आणि नंतर त्याच समस्येसह कोणी तोच फोरम थ्रेड पुन्हा शोधेल।

दुरुस्त केलेला विश्वास एका ओळीत सांगण्याइतका सोपा आहे: जुने पॅकेज हा क्लायंट एकदा तयार झाला आणि चालला याचा पुरावा आहे, आज रात्री तुमच्या बोर्डवर स्थापित होईल याचा पुरावा नाही। तीनही अक्ष तपासा, नंतर अपडेट करत राहू शकता असे चॅनेल निवडा।