Ĉu la malnova .deb de openfortivpn taŭgas por via Raspberry Pi?

Respondo en forumo donas al vi kompletan dosiernomon, kaj la dosiernomo aspektas kiel la solvo: unu .deb, unu komando, finite. Kion tiu ĉeno efektive kodas estas paketa versio, CPU-arkitekturo kaj la distribua suito, kontraŭ kiu ĝi estis konstruita en la tago, kiam iu skribis la afiŝon. Neniu el tiuj tri aŭtomate priskribas la panelon sur via skribotablo. La malnova elŝuto estas momentfoto de la situacio de unu maŝino, ne instalplano por la via.

Kion la dosiernomo silente fiksas

Legu nomon kiel openfortivpn_1.17.0-1_armhf.deb de dekstre maldekstren. La sufikso estas la arkitekturo, por kiu la binara dosiero estis kompilita, la meza kampo estas la revizio de upstream kaj pakado, kaj la implicita kvara kampo estas la biblioteka aro de la suito, en kiu ĝi estis konstruita.

En 64-bita instalado de Raspberry Pi OS la sistema arkitekturo estas arm64, do dpkg -i rifuzas pakon armhf pro malkongruo de arkitekturo. Eĉ kie multiarch ebligas la instaladon, la binara dosiero atendas bibliotekajn versiojn el la eldono, kontraŭ kiu ĝi estis konstruita, kaj pli nova baza sistemo eble jam ne havigas ilin. La rezulto estas instalita pako, kies plenumebla dosiero ne povas ekfunkcii, kaj tio estas la malsukceso, kiun homoj kutime misinterpretas kiel la kliento mem rompita.

Tio, ke la panelo estas ARM-aparato, ne igas ARM-pakon taŭga. Arkitekturo estas unu akso; eldono kaj ABI estas la aliaj du, kaj ili malsukcesas sendepende.

Demandu la distribuon antaŭ ol peti elŝutan ligilon

Ĉiu prizorgata kanalo povas diri al vi, kion ĝi instalus ĝuste nun. Rulu la peton sur la cela maŝino, kun la deponejoj, kiujn ĝi efektive uzas, antaŭ ol konsideri ajnan dosierotransigon.

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

Kandidata linio kun versio kaj deponeja nomo signifas, ke la distribuo jam havas konstruaĵon por ĉi tiu sistemo. Manko de kandidato, aŭ kandidato el suito, kiun vi ne intencis uzi, estas informo pri viaj fontoj, ne pri tio, ke la programaro ekzistas ie.

Se la refreŝigo de metadatenoj malsukcesas, tenu tiun malsukceson aparte de la paka demando. Nomresolvo, deponeja transporto, mankanta Release-subskribo kaj suito ĉe la fino de sia vivo ĉiuj rompas apt update antaŭ ol la kliento estas implikita. Ripari fontojn estas alia tasko ol elekti VPN-klienton, kaj miksi la du estas la maniero, kiel homoj finas montri aktualan sistemon al eksdata eldono.

Kion apt kontrolas, kaj kion elŝutita dosiero ne ricevas

Normala instalado sekvas subskriban ĉenon: la arkivo subskribas sian indekson, la indekso portas haketojn por ĉiu pako, kaj la pako devas kongrui. La referenco pri arkiva aŭtentikigo apartigas tiun ĉenon de la ideo kontroli subskribon alkroĉitan al ĉiu unuopa dosiero.

Dosiero konservita el malnova HTTP-ligilo havas nenion el tio. Ĝi alvenas sen deponeja identeco, ĝi ne estas ĝisdatigata, kiam la distribuo flikas la klienton, kaj nenio registras, kiu respondecas pri anstataŭigi ĝin. Tio ankoraŭ povas esti legitima elekto por administranto kun fiksita artefakto, sed la elekto devas veni kun posedanto, ie registrita kontrolsumo kaj plano por la sekva sekureca ĝisdatigo.

Subpremi subskribajn erarojn aŭ malŝalti TLS-kontrolon por teni malnovan instrukciaron funkcianta forigas la solan parton de la procezo, kiu kontrolis ion ajn. Restaŭru anstataŭe la malsukcesantan kontrolon.

Instalu la klienton, poste sencimigu la konekton aparte

Kiam ekzistas prizorgata kandidato, instalu ĝin per la normala reviziita transakcio kaj lasu la pakaĵadministrilon registri, kion ĝi faris.

Se la deplojo vere bezonas konstruaĵon el upstream, sekvu la aktualajn konstruinstrukciojn de la projekto kaj traktu ĝin kiel programaron, kiun vi nun prizorgas: evolupakaĵoj, pkg-config, la kaplinioj de la TLS-biblioteko kaj la PPP-demono estas veraj dependaĵoj, kaj same la forigproceduro, kiun vi bezonos poste.

Instalado estas nur la loka programara etapo. La kluzo devas akcepti la protokolon kaj aŭtentikigan fluon de la kliento, la kliento devas fidi la atestilon, kiun la kluzo prezentas, kaj la tunelo bezonas funkciantan PPP-tavolon plus itinerojn kaj posedanton de la solvilo. Kompletigita paka transakcio pruvas nenion pri tio, ĉu la kluzo akceptas la konton aŭ ĉu la privata gamo estas atingebla. Testu ĉiun tavolon tie, kie ĝi rompiĝas, anstataŭ reruli la instalilon.

La plano, kiu devus anstataŭigi la malnovan dosiernomon

Unue skribu la identecon de la platformo: OS-eldono, arkitekturo kaj la uzata fontolisto. Poste nomu la rajtigitan lokon, de kie la pako venas — ĉu distribua deponejo, vendista deponejo kun fiksita ŝlosilo aŭ konstruaĵo, kiun vi mem kompilas kaj pakas.

Fine nomu la prizorganton kaj la ĝisdatigan vojon. Pi, kiu rulas klienton, kiun neniu posedas, daŭre funkcios ĝis la unua biblioteka ĝisdatigo, kaj tiam la saman forumfadenon denove trovos iu kun la sama problemo.

La korektita konvinko estas sufiĉe simpla por esprimi en unu linio: la malnova pako estas pruvo, ke la kliento iam estis konstruita kaj funkciis, ne pruvo, ke ĝi instalos sur vian panelon ĉi-vespere. Kontrolu la tri aksojn, poste elektu kanalon, kiun vi povas daŭre ĝisdatigi.