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

Eit svar på eit forum gir deg eit fullstendig filnamn, og namnet ser ut som løysinga: éin .deb, éin kommando, ferdig. Det strengen faktisk kodar, er ein pakkeversjon, ein CPU-arkitektur og distribusjonssuitten han vart bygd mot den dagen nokon skreiv innlegget. Ingen av dei tre skildrar automatisk kortet på skrivebordet ditt. Den gamle nedlastinga er eit augneblinksbilete av situasjonen til éin maskin, ikkje ein installasjonsplan for din.

Kva filnamnet stille låser

Les eit namn som openfortivpn_1.17.0-1_armhf.deb frå høgre mot venstre. Endinga er arkitekturen binæren vart kompilert for, det midtre feltet er upstream- og pakkerevisjonen, og det implisitte fjerde feltet er bibliotekssettet til suitten han vart bygd i.

På ein 64-bitars Raspberry Pi OS-installasjon er systemarkitekturen arm64, så dpkg -i avviser ein armhf-pakke på grunn av arkitekturkonflikt. Sjølv der multiarch gjer installasjonen mogleg, ventar binæren bibliotekversjonar frå utgivinga han vart bygd mot, og eit nyare grunnsystem gir dei kanskje ikkje lenger. Resultatet er ein installert pakke der den køyrbare fila ikkje startar, og det er feilen folk vanlegvis feiltolkar som at klienten sjølv er øydelagd.

At kortet er ein ARM-eining gjer ikkje ein ARM-pakke passande. Arkitektur er éin akse; utgiving og ABI er dei to andre, og dei feilar uavhengig.

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

Kvar vedlikehalden kanal kan fortelje deg kva han ville installert akkurat no. Køyr spørjinga på målmaskina, med depota ho faktisk brukar, før du vurderer noka filoverføring.

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

Ei kandidatlinje med ein versjon og eit depotnamn tyder at distribusjonen allereie har ei bygging for dette systemet. Ingen kandidat, eller ein kandidat frå ein suite du ikkje hadde tenkt å bruke, er informasjon om kjeldene dine, ikkje om korvidt programvara finst ein stad.

Viss oppdateringa av metadata mislukkast, hald den feilen skild frå pakkespørsmålet. Namneoppslag, depottransport, ein manglande Release-signatur og ein suite ved slutten av levetida bryt alle apt update før klienten er involvert. Å reparere kjelder er ei anna oppgåve enn å velje ein VPN-klient, og å blande dei to er korleis folk endar med å peike eit gjeldande system mot ei utdatert utgiving.

Kva apt verifiserer, og kva ei nedlasta fil ikkje får

Ein normal installasjon følgjer ei signaturkjede: arkivet signerer indeksen sin, indeksen ber hashar for kvar pakke, og pakken må stemme. referanse for arkivautentisering skil den kjeda frå idéen om å kontrollere ein signatur som er knytt til kvar einskild fil.

Ei fil lagra frå ei gammal HTTP-lenke har ingenting av dette. Ho kjem utan depotidentitet, ho vert ikkje oppdatert når distribusjonen patchar klienten, og ingenting registrerer kven som er ansvarleg for å erstatte ho. Det kan framleis vere eit legitimt val for ein administrator med ein fastlåst artefakt, men valet må kome med ein eigar, ein kontrollsum registrert ein stad og ein plan for neste tryggleiksoppdatering.

Å undertrykkje signaturfeil eller slå av TLS-verifisering for å halde ein gammal instruksjon i gang fjernar den einaste delen av prosessen som kontrollerte noko. Gjenopprett heller kontrollen som feilar.

Installer klienten, og feilsøk deretter tilkoblinga separat

Når det finst ein vedlikehalden kandidat, installer han gjennom den vanlege gjennomgåtte transaksjonen og lat pakkehandsamaren registrere kva han gjorde.

Viss utrullinga verkeleg treng ei bygging frå upstream, følg dei gjeldande byggjeinstruksjonane til prosjektet og handsam henne som programvare du no vedlikeheld: utviklingspakkar, pkg-config, TLS-biblioteket sine hovud og PPP-demonen er reelle avhengnader, og det er fjerningsprosedyren du treng seinare òg.

Installasjon er berre det lokale programvaretinnet. Gatewayen må godta protokollen og autentiseringsflyten til klienten, klienten må stole på sertifikatet gatewayen presenterer, og tunnelen treng eit fungerande PPP-lag pluss ruter og ein resolver-eigar. Ein fullført pakketransaksjon beviser ingenting om korvidt gatewayen godtek kontoen eller om det private området er tilgjengeleg. Test kvart lag der det bryt i staden for å køyre installasjonsprogrammet på nytt.

Planen som bør erstatte det gamle filnamnet

Skriv først ned identiteten til plattforma: OS-utgiving, arkitektur og kjelda som vert brukt. Namngje deretter den autoriserte staden pakken kjem frå, anten det er eit distribusjonsdepot, eit leverandørdepot med ein fastlåst nøkkel eller ei bygging du kompilerer og pakkar sjølv.

Til slutt namngjev du vedlikehaldaren og oppdateringsvegen. Ein Pi som køyrer ein klient ingen eig, vil halde fram med å verke til den første bibliotekoppdateringa, og då vil den same forumtråden verte funnen igjen av nokon med det same problemet.

Den korrigerte oppfatninga er enkel nok til å seiast på éi linje: den gamle pakken er bevis på at klienten ein gong vart bygd og køyrde, ikkje bevis på at han vert installert på kortet ditt i kveld. Kontroller dei tre aksane, og vel deretter ein kanal du kan halde fram med å oppdatere.