Este vechiul .deb openfortivpn potrivit pentru Raspberry Pi-ul tău?

Un răspuns pe un forum îți dă un nume complet de fișier, iar numele arată ca soluția: un .deb, o comandă, gata. Ce codifică de fapt acel șir este o versiune de pachet, o arhitectură de procesor și suita distribuției împotriva căreia a fost compilat în ziua în care cineva a scris mesajul. Niciuna dintre acestea trei nu descrie automat placa de pe biroul tău. Descărcarea veche este o instantanee a situației unei mașini, nu un plan de instalare pentru a ta.

Ce fixează în tăcere numele fișierului

Citește un nume precum openfortivpn_1.17.0-1_armhf.deb de la dreapta la stânga. Sufixul este arhitectura pentru care a fost compilat binarul, câmpul din mijloc este revizia upstream și de împachetare, iar al patrulea câmp implicit este setul de biblioteci al suitei în care a fost construit.

Pe o instalare Raspberry Pi OS pe 64 de biți, arhitectura sistemului este arm64, așa că dpkg -i refuză un pachet armhf din cauza nepotrivirii de arhitectură. Chiar și acolo unde multiarch permite instalarea, binarul așteaptă versiuni de bibliotecă din versiunea împotriva căreia a fost compilat, iar un sistem de bază mai nou s-ar putea să nu le mai furnizeze. Rezultatul este un pachet instalat al cărui executabil nu pornește, și aceasta este defecțiunea pe care oamenii o interpretează de obicei greșit ca fiind clientul însuși defect.

Faptul că placa este un dispozitiv ARM nu face un pachet ARM potrivit. Arhitectura este o axă; versiunea și ABI sunt celelalte două, și eșuează independent.

Întreabă distribuția înainte de a cere un link de descărcare

Fiecare canal întreținut îți poate spune ce ar instala chiar acum. Rulează interogarea pe mașina țintă, cu depozitele pe care le folosește de fapt, înainte de a lua în considerare orice transfer de fișier.

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

O linie de candidat cu o versiune și un nume de depozit înseamnă că distribuția are deja o compilare pentru acest sistem. Absența unui candidat, sau un candidat dintr-o suită pe care nu intenționai să o folosești, este informație despre sursele tale, nu despre faptul că software-ul există undeva.

Dacă reîmprospătarea metadatelor eșuează, ține acea eșuare separată de întrebarea despre pachet. Rezolvarea numelor, transportul depozitelor, o semnătură Release lipsă și o suită la sfârșitul vieții rup toate apt update înainte ca clientul să fie implicat. Repararea surselor este o altă sarcină decât alegerea unui client VPN, iar amestecarea celor două este modul în care oamenii ajung să îndrepte un sistem actual către o versiune învechită.

Ce verifică apt și ce nu primește un fișier descărcat

O instalare normală urmează un lanț de semnături: arhiva își semnează indexul, indexul poartă hash-uri pentru fiecare pachet, iar pachetul trebuie să corespundă. referință de autentificare a arhivei separă acel lanț de ideea de a verifica o semnătură atașată fiecărui fișier individual.

Un fișier salvat dintr-un link HTTP vechi nu are nimic din toate acestea. Ajunge fără identitate de depozit, nu este actualizat când distribuția remediază clientul, și nimic nu înregistrează cine este responsabil pentru înlocuirea lui. Aceasta poate fi încă o alegere legitimă pentru un administrator cu un artefact fixat, dar alegerea trebuie să vină cu un proprietar, o sumă de control înregistrată undeva și un plan pentru următoarea actualizare de securitate.

Suprimarea erorilor de semnătură sau dezactivarea verificării TLS pentru a menține o instrucțiune veche în funcțiune elimină singura parte a procesului care verifica ceva. Restabilește în schimb verificarea care eșuează.

Instalează clientul, apoi depanează conexiunea separat

Când există un candidat întreținut, instalează-l prin tranzacția revizuită normală și lasă managerul de pachete să înregistreze ce a făcut.

Dacă implementarea are într-adevăr nevoie de o compilare din upstream, urmează instrucțiunile actuale de compilare ale proiectului și trateaz-o ca software pe care îl întreții acum: pachetele de dezvoltare, pkg-config, antetele bibliotecii TLS și demonul PPP sunt dependențe reale, la fel ca procedura de eliminare de care vei avea nevoie mai târziu.

Instalarea este doar etapa locală de software. Gateway-ul trebuie să accepte protocolul și fluxul de autentificare al clientului, clientul trebuie să aibă încredere în certificatul prezentat de gateway, iar tunelul are nevoie de un strat PPP funcțional plus rute și un proprietar al resolverului. O tranzacție de pachet finalizată nu dovedește nimic despre dacă gateway-ul acceptă contul sau dacă intervalul privat este accesibil. Testează fiecare strat acolo unde se rupe, în loc să rulezi din nou instalatorul.

Planul care ar trebui să înlocuiască vechiul nume de fișier

Scrie mai întâi identitatea platformei: versiunea sistemului, arhitectura și lista surselor folosite. Apoi numește locul autorizat de unde provine pachetul, fie că este un depozit de distribuție, un depozit de furnizor cu o cheie fixată sau o compilare pe care o compilezi și o împachetezi singur.

În final, numește întreținătorul și calea de actualizare. Un Pi care rulează un client pe care nimeni nu îl deține va funcționa până la prima actualizare de bibliotecă, iar apoi cineva cu aceeași problemă va găsi din nou același fir de forum.

Convingerea corectată este destul de simplă pentru a fi spusă într-o singură linie: pachetul vechi este dovada că clientul a fost cândva compilat și a rulat, nu dovada că se va instala pe placa ta în seara aceasta. Verifică cele trei axe, apoi alege un canal pe care îl poți actualiza în continuare.