Er den gamle openfortivpn .deb riktig for Raspberry Pi-en din?

Et svar på et forum gir deg et fullstendig filnavn, og filnavnet ser ut som løsningen: én .deb, én kommando, ferdig. Det strengen faktisk koder, er en pakkeversjon, en CPU-arkitektur og distribusjonssuitten den ble bygget mot den dagen noen skrev innlegget. Ingen av de tre beskriver automatisk kortet på skrivebordet ditt. Den gamle nedlastingen er et øyeblikksbilde av situasjonen til én maskin, ikke en installasjonsplan for din.

Hva filnavnet stille låser

Les et navn som openfortivpn_1.17.0-1_armhf.deb fra høyre mot venstre. Endelsen er arkitekturen binæren ble kompilert for, det midtre feltet er upstream- og pakkerevisjonen, og det implisitte fjerde feltet er bibliotekssettet til suitten den ble bygget i.

På en 64-biters Raspberry Pi OS-installasjon er systemarkitekturen arm64, så dpkg -i avviser en armhf-pakke på grunn av arkitekturkonflikt. Selv der multiarch gjør installasjon mulig, forventer binæren bibliotekversjoner fra utgivelsen den ble bygget mot, og et nyere grunnsystem gir dem kanskje ikke lenger. Resultatet er en installert pakke der den kjørbare filen ikke starter, og det er feilen folk vanligvis feiltolker som at klienten selv er ødelagt.

At kortet er en ARM-enhet gjør ikke en ARM-pakke passende. Arkitektur er én akse; utgivelse og ABI er de to andre, og de feiler uavhengig.

Spør distribusjonen før du spør om en nedlastingslenke

Hver vedlikeholdt kanal kan fortelle deg hva den ville installert akkurat nå. Kjør spørringen på målmaskinen, med depotene den faktisk bruker, før du vurderer noen filoverføring.

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

En kandidatlinje med en versjon og et depotnavn betyr at distribusjonen allerede har en bygging for dette systemet. Ingen kandidat, eller en kandidat fra en suite du ikke hadde tenkt å bruke, er informasjon om kildene dine, ikke om hvorvidt programvaren finnes et sted.

Hvis oppdateringen av metadata mislykkes, hold den feilen adskilt fra pakkespørsmålet. Navneoppslag, depottransport, en manglende Release-signatur og en suite ved slutten av levetiden bryter alle apt update før klienten er involvert. Å reparere kilder er en annen oppgave enn å velge en VPN-klient, og å blande de to er hvordan folk ender med å peke et gjeldende system mot en utdatert utgivelse.

Hva apt verifiserer, og hva en nedlastet fil ikke får

En normal installasjon følger en signaturkjede: arkivet signerer indeksen sin, indeksen bærer hasher for hver pakke, og pakken må stemme. referanse for arkivautentisering skiller den kjeden fra ideen om å kontrollere en signatur som er knyttet til hver enkelt fil.

En fil lagret fra en gammel HTTP-lenke har ingenting av dette. Den ankommer uten depotidentitet, den oppdateres ikke når distribusjonen patcher klienten, og ingenting registrerer hvem som er ansvarlig for å erstatte den. Det kan fortsatt være et legitimt valg for en administrator med et låst artefakt, men valget må komme med en eier, en kontrollsum registrert et sted og en plan for neste sikkerhetsoppdatering.

Å undertrykke signaturfeil eller slå av TLS-verifisering for å holde en gammel instruksjon i gang fjerner den eneste delen av prosessen som kontrollerte noe. Gjenopprett heller kontrollen som feiler.

Installer klienten, og feilsøk deretter tilkoblingen separat

Når det finnes en vedlikeholdt kandidat, installer den gjennom den vanlige gjennomgåtte transaksjonen og la pakkebehandleren registrere hva den gjorde.

Hvis utrullingen virkelig trenger en bygging fra upstream, følg prosjektets gjeldende byggeinstruksjoner og behandle den som programvare du nå vedlikeholder: utviklingspakker, pkg-config, TLS-bibliotekets headere og PPP-demonen er reelle avhengigheter, og det er fjerningsprosedyren du trenger senere også.

Installasjon er bare det lokale programvaretinnet. Gatewayen må godta klientens protokoll og autentiseringsflyt, klienten må stole på sertifikatet gatewayen presenterer, og tunnelen trenger et fungerende PPP-lag pluss ruter og en resolver-eier. En fullført pakketransaksjon beviser ingenting om hvorvidt gatewayen godtar kontoen eller om det private området er tilgjengelig. Test hvert lag der det bryter i stedet for å kjøre installasjonsprogrammet på nytt.

Planen som bør erstatte det gamle filnavnet

Skriv først ned plattformens identitet: OS-utgivelse, arkitektur og kildelisten som brukes. Navngi deretter det autoriserte stedet pakken kommer fra, enten det er et distribusjonsdepot, et leverandørdepot med en låst nøkkel eller en bygging du kompilerer og pakker selv.

Til slutt navngir du vedlikeholderen og oppdateringsveien. En Pi som kjører en klient ingen eier, vil fortsette å virke til den første bibliotekoppdateringen, og da vil den samme forumtråden bli funnet igjen av noen med det samme problemet.

Den korrigerte oppfatningen er enkel nok til å sies på én linje: den gamle pakken er bevis på at klienten en gang ble bygget og kjørte, ikke bevis på at den installeres på kortet ditt i kveld. Kontroller de tre aksene, og velg deretter en kanal du kan fortsette å oppdatere.