Hentar gamli openfortivpn .deb fyrir Raspberry Pi hjá þér?
Geymdur armhf .deb festir útgáfu sem Pi-tölvan þín passar ef til vill ekki lengur við. Athugaðu útgáfu stýrikerfisins, byggingu pakkans og uppfærslugjafann áður en þú setur hann upp.
Svar á spjallborði gefur þér fullt skráarnafn, og nafnið lítur út eins og lausnin: eitt .deb, ein skipun, búið. Það sem strengurinn kóðar í raun er pakkaútgáfa, örgjörvabygging og dreifingarsettið sem hann var byggður gegn þann daginn sem einhver skrifaði færsluna. Ekkert þessara þriggja lýsir sjálfkrafa borðinu á skrifborðinu þínu. Gamla niðurhalið er skyndimynd af stöðu einnar vélar, ekki uppsetningarplan fyrir þína.
Hvað skráarnafnið festir hljóðlega
Lestu nafn eins og openfortivpn_1.17.0-1_armhf.deb frá hægri til vinstri. Viðskeytið er byggingin sem tvíundaskráin var þýdd fyrir, miðreiturinn er uppfærsla upstream og pökkunar, og hinn óbeini fjórði reitur er bókasafnssett settisins sem hann var byggður í.
Á 64-bita uppsetningu Raspberry Pi OS er kerfisbyggingin arm64, svo dpkg -i hafnar armhf pakka vegna ósamræmis í byggingu. Jafnvel þar sem multiarch gerir uppsetningu mögulega býst tvíundaskráin við bókasafnsútgáfum frá þeirri útgáfu sem hún var byggð gegn, og nýrra grunnkerfi gæti ekki lengur veitt þær. Niðurstaðan er uppsettur pakki þar sem keyrsluskráin ræsist ekki, og það er bilunin sem fólk túlkar venjulega rangt sem svo að biðlarinn sjálfur sé bilaður.
Það að borðið sé ARM-tæki gerir ARM-pakka ekki viðeigandi. Bygging er ein ás; útgáfa og ABI eru hinir tveir, og þeir bregðast óháð.
Spyrðu dreifinguna áður en þú biður um niðurhalstengil
Sérhver viðhaldið rás getur sagt þér hvað hún myndi setja upp núna. Keyrðu fyrirspurnina á markvélinni, með þeim geymslum sem hún notar í raun, áður en þú íhugar nokkra flutning skráa.
cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpnFrambjóðendalína með útgáfu og geymslunafni þýðir að dreifingin hefur þegar byggingu fyrir þetta kerfi. Enginn frambjóðandi, eða frambjóðandi úr setti sem þú ætlaðir ekki að nota, er upplýsing um gjafana þína, ekki um hvort hugbúnaðurinn sé til einhvers staðar.
Ef endurnýjun lýsigagna mistekst skaltu halda þeirri mistökum aðskildum frá pakkaspurningunni. Nafnaupplausn, flutningur geymslna, vantar Release-undirskrift og sett á lífslokum brjóta öll apt update áður en biðlarinn kemur við sögu. Að laga gjafana er annað verkefni en að velja VPN-biðlara, og að blanda þessu tvennu er leiðin sem fólk fer til að beina núverandi kerfi að úreltri útgáfu.
Hvað apt staðfestir og hvað niðurhalað skrá fær ekki
Venjuleg uppsetning fylgir undirskriftarkeðju: skjalasafnið undirritar eigin vísitölu, vísitalan ber tætigildi fyrir hvern pakka, og pakkinn verður að passa. tilvísun í auðkenningu skjalasafns aðgreinir þá keðju frá hugmyndinni um að athuga undirskrift sem fest er við hverja einstaka skrá.
Skrá sem vistuð er af gömlum HTTP-tengli hefur ekkert af þessu. Hún kemur án auðkenningar geymslu, er ekki uppfærð þegar dreifingin plástrar biðlarann, og ekkert skráir hver ber ábyrgð á að skipta henni út. Það getur samt verið lögmætur valkostur fyrir stjórnanda með fastbundið gagn, en valkosturinn verður að koma með eiganda, prófsummu sem skráð er einhvers staðar og áætlun fyrir næstu öryggisuppfærslu.
Að bæla undirskriftarvillur eða slökkva á TLS-staðfestingu til að halda gömlum leiðbeiningum gangandi fjarlægir eina hluta ferlisins sem var að athuga eitthvað. Endurheimtu frekar athugunina sem bregst.
Settu biðlarann upp, og kembtu svo tengingunni sérstaklega
Þegar viðhaldið frambjóðandi er til skaltu setja hann upp með venjulegri yfirförnu færslu og láta pakkastjórann skrá hvað hann gerði.
Ef uppsetningin þarf raunverulega byggingu frá upstream skaltu fylgja núverandi byggingarleiðbeiningum verkefnisins og meðhöndla hana sem hugbúnað sem þú viðheldur núna: þróunarpakkar, pkg-config, hausar TLS-safnsins og PPP-púkinn eru raunverulegar ósjálfstæður, og svo er fjarlægingaraðferðin sem þú munt þurfa síðar.
Uppsetning er aðeins staðbundið hugbúnaðarstig. Hliðið verður að samþykkja samskiptareglur og auðkenningarflæði biðlarans, biðlarinn verður að treysta vottorðinu sem hliðið kynnir, og göngin þurfa vinnandi PPP-lag auk leiða og eiganda resolver. Lokið pakkafærsla sannar ekkert um hvort hliðið samþykki reikninginn eða hvort einkasviðið sé aðgengilegt. Prófaðu hvert lag þar sem það brotnar í stað þess að keyra uppsetningarforritið aftur.
Áætlunin sem ætti að koma í stað gamla skráarnafnsins
Skrifaðu fyrst auðkenni vettvangsins: útgáfu stýrikerfis, byggingu og lista yfir gjafana sem notaðir eru. Nafngreindu síðan leyfilega staðinn sem pakkinn kemur frá, hvort sem það er dreifingargeymsla, söluaðilageymsla með fastbundnum lykli eða bygging sem þú þýðir og pakkar sjálfur.
Að lokum skaltu nafngreina viðhaldanda og uppfærsluleiðina. Pi sem keyrir biðlara sem enginn á mun halda áfram að virka þar til fyrsta bókasafnsuppfærslan kemur, og þá mun einhver með sama vandamál finna sama spjallþráðinn aftur.
Leiðrétta trúin er nógu einföld til að segja í einni línu: gamli pakkinn er sönnun þess að biðlarinn var einu sinni byggður og keyrður, ekki sönnun þess að hann muni setjast upp á borðið þitt í kvöld. Athugaðu ásana þrjá og veldu síðan rás sem þú getur haldið áfram að uppfæra.