Is daardie ou openfortivpn .deb reg vir jou Raspberry Pi?

’n Antwoord op die forum gee jou 'n volledige lêernaam, en die lêernaam lyk soos die oplossing: een .deb, een opdrag, klaar. Wat daardie string eintlik verberg, is 'n pakketweergawe, 'n SVE-argitektuur en die distribusie-suite waarteen dit gebou is op die dag toe iemand die plasing geskryf het. Nie een van dié drie beskryf outomaties die bord op jou lessenaar nie. Die ou aflaai is 'n momentopname van een masjien se situasie, nie 'n installasieplan vir joune nie.

Wat die lêernaam stilweg vaspen

Lees 'n naam soos openfortivpn_1.17.0-1_armhf.deb van regs na links. Die agtervoegsel is die argitektuur waarvoor die binêre lêer saamgestel is, die middelveld is die opstroom- en verpakkingsweergawe, en die implisiete vierde veld is die biblioteekstel van die suite waarin dit gebou is.

Op 'n 64-bis Raspberry Pi OS-installasie is die stelselargitektuur arm64, dus weier dpkg -i 'n armhf-pakket weens 'n argitektuur-mismatch. Selfs waar multiarch dit laat installeer, verwag die binêre lêer biblioteekweergawes uit die uitgawe waarteen dit gebou is, en 'n nuwer basisstelsel verskaf dit dalk nie meer nie. Die resultaat is 'n geïnstalleerde pakket waarvan die uitvoerbare lêer nie kan begin nie, wat die fout is wat mense gewoonlik verkeerd verstaan as die kliënt self wat stukkend is.

Die feit dat die bord 'n ARM-toestel is, maak nie 'n ARM-pakket gepas nie. Argitektuur is een as; uitgawe en ABI is die ander, en hulle faal onafhanklik.

Vra die distribusie voordat jy na 'n aflaaiskakel vra

Elke onderhoude kanaal kan jou sê wat dit nou sou installeer. Voer die navraag op die teikenmasjien uit, met die repositories wat dit werklik gebruik, voordat jy enige lêeroordrag oorweeg.

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

'n Kandidaatlyn met 'n weergawe en 'n repository-naam beteken die distribusie het reeds 'n bou vir hierdie stelsel. Geen kandidaat nie, of 'n kandidaat uit 'n suite wat jy nie bedoel het om te gebruik nie, is inligting oor jou bronne eerder as oor die sagteware wat êrens bestaan.

As die hernuwing van metadata misluk, hou daardie mislukking apart van die pakketvraag. Naamresolusie, repository-vervoer, 'n ontbrekende Release-handtekening en 'n einde-van-lewe-suite breek almal apt update voordat die kliënt betrokke is. Die regmaak van bronne is 'n ander taak as die kies van 'n VPN-kliënt, en om die twee te vermeng, is hoe mense 'n huidige stelsel op 'n verouderde uitgawe laat wys.

Wat apt verifieer, en wat 'n afgelaaide lêer nie kry nie

'n Normale installasie volg 'n handtekeningketting: die argief onderteken sy indeks, die indeks dra hashes vir elke pakket, en die pakket moet ooreenstem. Die argiefverifikasie-verwysing skei daardie ketting van die idee om 'n handtekening te kontroleer wat aan elke individuele lêer geheg is.

'n Lêer wat uit 'n ou HTTP-skakel gestoor is, het niks daarvan nie. Dit kom sonder 'n repository-identiteit, dit word nie opgedateer wanneer die distribusie die kliënt pleister nie, en niks teken aan wie verantwoordelik is om dit te vervang nie. Dit kan steeds 'n wettige keuse wees vir 'n administrateur met 'n vasgepen artefak, maar die keuse moet kom met 'n eienaar, 'n kontrolesom wat êrens aangeteken is, en 'n plan vir die volgende sekuriteitsopdatering.

Om handtekeningfoute te onderdruk of TLS-verifikasie af te skakel om 'n ou instruksie aan die gang te hou, verwyder die enigste deel van die proses wat enigiets nagegaan het. Herstel eerder die mislukte kontrole.

Installeer die kliënt, debug dan die verbinding apart

Wanneer 'n onderhoude kandidaat bestaan, installeer dit deur die normale nagegane transaksie en laat die pakketbestuurder aanteken wat dit gedoen het.

As die ontplooiing werklik 'n opstroom-bou nodig het, volg die projek se huidige bou-instruksies en behandel dit as sagteware wat jy nou onderhou: ontwikkelingspakkette, pkg-config, die TLS-biblioteek-koppe en die PPP-daemon is werklike afhanklikhede, en so ook die verwyderingsprosedure wat jy later sal wil hê.

Installasie is slegs die plaaslike sagteware-stadium. Die poort moet die kliënt se protokol en verifikasiestroom aanvaar, die kliënt moet die sertifikaat vertrou wat die poort aanbied, en die tonnel het 'n werkende PPP-laag plus roetes en 'n resolver-eienaar nodig. 'n Voltooide pakkettransaksie bewys niks oor of die poort die rekening aanvaar of of die private reeks bereikbaar is nie. Toets elke laag waar dit breek in plaas daarvan om die installeerder weer te laat loop.

Die plan wat die ou lêernaam moet vervang

Skryf eers die platformidentiteit neer: OS-weergawe, argitektuur en die bronlys wat gebruik word. Noem dan die gemagtigde plek waar die pakket vandaan kom, of dit 'n distribusie-repository, 'n verskaffer-repository met 'n vasgepen sleutel of 'n bou is wat jy self saamstel en verpak.

Noem laastens die instandhouer en die opdateringspad. 'n Pi wat 'n kliënt laat loop wat niemand besit nie, sal aanhou werk tot die eerste biblioteek-opgradering, en dan sal dieselfde forumdraad weer deur iemand met dieselfde probleem gevind word.

Die reggestelde oortuiging is eenvoudig genoeg om in een lyn te stel: die ou pakket is bewyse dat die kliënt eens gebou en geloop het, nie bewyse dat dit vanaand op jou bord sal installeer nie. Kontroleer die drie asse en kies dan 'n kanaal wat jy kan bly opdateer.