Megfelelő-e a régi openfortivpn .deb a Raspberry Pi-jéhez?

Egy fórumválasz teljes fájlnevet ad, és a fájlnév úgy tűnik, mintha a megoldás lenne: egy .deb, egy parancs, kész. Amit ez a karakterlánc valójában kódol, az egy csomagverzió, egy CPU-architektúra és az a disztribúciós csomagkészlet, amelyhez azon a napon építették, amikor valaki a bejegyzést írta. Ezek közül egyik sem írja le automatikusan az asztalán álló lapkát. A régi letöltés egy gép helyzetének pillanatképe, nem az ön telepítési terve.

Mit rögzít csendesen a fájlnév

Olvasson el egy openfortivpn_1.17.0-1_armhf.deb-szerű nevet jobbról balra. Az utótag az architektúra, amelyre a bináris fájlt fordították, a középső mező az upstream és a csomagolási revízió, a hallgatólagos negyedik mező pedig annak a csomagkészletnek a könyvtárkészlete, amelyben építették.

Egy 64 bites Raspberry Pi OS telepítésen a rendszerarchitektúra arm64, ezért a dpkg -i architektúra-eltérés miatt elutasítja a armhf csomagot. Még ott is, ahol a multiarch lehetővé teszi a telepítést, a bináris a kiadás könyvtárverzióit várja, amelyhez építették, és egy újabb alaprendszer ezeket már nem biztos, hogy biztosítja. Az eredmény egy telepített csomag, amelynek a végrehajtható fájlja nem indul el, és ez az a hiba, amelyet az emberek általában tévesen magának a kliensnek a hibájaként értelmeznek.

Attól, hogy a lapka ARM-eszköz, az ARM-csomag még nem lesz megfelelő. Az architektúra az egyik tengely; a kiadás és az ABI a másik kettő, és egymástól függetlenül hibáznak.

Kérdezze meg a disztribúciót, mielőtt letöltési linket kérne

Minden karbantartott csatorna meg tudja mondani, mit telepítene most. Futtassa a lekérdezést a célgépen, azokkal a tárolókkal, amelyeket ténylegesen használ, mielőtt bármilyen fájlátvitelre gondolna.

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

Egy verziót és tárolónevet tartalmazó jelölt sor azt jelenti, hogy a disztribúciónak már van buildje ehhez a rendszerhez. Ha nincs jelölt, vagy a jelölt olyan csomagkészletből jön, amelyet nem szándékozott használni, az az ön forrásairól szóló információ, nem arról, hogy a szoftver valahol létezik.

Ha a metaadatok frissítése meghiúsul, tartsa ezt a hibát elkülönítve a csomag kérdésétől. A névfeloldás, a tároló átvitele, a hiányzó Release-aláírás és egy életciklusa végén lévő csomagkészlet mind megtöri a apt update parancsot, mielőtt a kliens egyáltalán szóba kerülne. A források javítása más feladat, mint egy VPN-kliens kiválasztása, és a kettő összekeverése az az út, amelyen az emberek egy jelenlegi rendszert egy elavult kiadásra irányítanak.

Mit ellenőriz az apt, és mit nem kap meg egy letöltött fájl

Egy normál telepítés aláírásláncot követ: az archívum aláírja a saját indexét, az index minden csomaghoz hash-eket tartalmaz, és a csomagnak egyeznie kell. Az archívum-hitelesítési referencia elválasztja ezt a láncot attól az elképzeléstől, hogy minden egyes fájlhoz csatolt aláírást ellenőrizzünk.

Egy régi HTTP-linkről mentett fájlnak ebből semmi sincs benne. Tárolóidentitás nélkül érkezik, nem frissül, amikor a disztribúció javítja a klienst, és semmi sem rögzíti, hogy ki felelős a lecseréléséért. Ez még mindig legitim választás lehet egy rögzített artefaktummal rendelkező rendszergazdának, de a választáshoz tulajdonos, valahol rögzített ellenőrzőösszeg és terv kell a következő biztonsági frissítésre.

Az aláírási hibák elnyomása vagy a TLS-ellenőrzés kikapcsolása, hogy egy régi utasítás tovább működjön, eltávolítja a folyamat egyetlen részét, amely bármit is ellenőrzött. Inkább állítsa helyre a meghiúsuló ellenőrzést.

Telepítse a klienst, majd külön hibakeressen a kapcsolatot

Ha létezik karbantartott jelölt, telepítse a szokásos ellenőrzött tranzakcióval, és hagyja, hogy a csomagkezelő rögzítse, mit tett.

Ha a telepítés valóban upstream buildet igényel, kövesse a projekt jelenlegi buildutasításait, és kezelje úgy, mint az ön által most karbantartott szoftvert: a fejlesztői csomagok, a pkg-config, a TLS-könyvtár fejlécei és a PPP-démon valódi függőségek, ahogy az a eltávolítási eljárás is, amelyre később szüksége lesz.

A telepítés csak a helyi szoftveres szakasz. Az átjárónak el kell fogadnia a kliens protokollját és hitelesítési folyamatát, a kliensnek meg kell bíznia az átjáró által bemutatott tanúsítványban, a csatornának pedig működő PPP-rétegre, valamint útvonalakra és egy feloldó tulajdonosára van szüksége. Egy befejezett csomagtranzakció semmit sem bizonyít arról, hogy az átjáró elfogadja-e a fiókot, vagy hogy a privát tartomány elérhető-e. Minden réteget ott teszteljen, ahol eltörik, ahelyett hogy újra futtatná a telepítőt.

A terv, amelynek fel kellene váltania a régi fájlnevet

Először írja le a platform identitását: operációsrendszer-kiadás, architektúra és a használt forráslista. Ezután nevezze meg azt az engedélyezett helyet, ahonnan a csomag származik — legyen az disztribúciós tároló, rögzített kulcsú gyártói tároló vagy saját maga által fordított és csomagolt build.

Végül nevezze meg a karbantartót és a frissítési útvonalat. Egy Pi, amely olyan klienst futtat, amelynek nincs tulajdonosa, az első könyvtárfrissítésig fog működni, és akkor valaki ugyanazzal a problémával újra megtalálja ugyanazt a fórumtémát.

A helyesbített hit egyszerűen megfogalmazható egy sorban: a régi csomag bizonyítéka annak, hogy a klienst egyszer megépítették és futtatták, nem bizonyítéka annak, hogy ma este települni fog a lapkájára. Ellenőrizze a három tengelyt, majd válasszon olyan csatornát, amelyet folyamatosan frissíthet.