Angkop ba ang lumang .deb ng openfortivpn para sa iyong Raspberry Pi?

Binibigyan ka ng sagot sa forum ng kumpletong filename, at ang pangalan ay mukhang solusyon: isang .deb, isang utos, tapos. Ang talagang ine-encode ng string na iyon ay bersyon ng package, arkitektura ng CPU at ang suite ng distribusyon kung laban dito ito binuo noong araw na isinulat ng isang tao ang post. Wala sa tatlong iyon ang awtomatikong naglalarawan sa board sa iyong mesa. Ang lumang download ay isang snapshot ng sitwasyon ng isang makina, hindi isang plano ng pag-install para sa iyo.

Ano ang tahimik na ipinipin ng filename

Basahin ang pangalang tulad ng openfortivpn_1.17.0-1_armhf.deb mula kanan pakaliwa. Ang suffix ay ang arkitekturang kinabuo ng binary, ang gitnang field ay ang upstream at packaging revision, at ang implicit na ikaapat na field ay ang set ng library ng suite kung saan ito binuo.

Sa 64-bit na pag-install ng Raspberry Pi OS ang arkitektura ng system ay arm64, kaya tinatanggihan ng dpkg -i ang isang armhf package dahil sa hindi pagtutugma ng arkitektura. Kahit saan pinapayagan ng multiarch ang pag-install, inaasahan ng binary ang mga bersyon ng library mula sa release kung laban dito ito binuo, at maaaring hindi na ibigay ng mas bagong base system ang mga ito. Ang resulta ay isang naka-install na package kung saan hindi tumatakbo ang executable, at ito ang kabiguang karaniwang maling binibigyang-kahulugan ng mga tao na ang kliyente mismo ang sira.

Ang pagiging ARM device ng board ay hindi gumagawa ng ARM package na angkop. Ang arkitektura ay isang axis; ang release at ABI ang dalawa pa, at nabibigo sila nang independiyente.

Tanungin ang distribusyon bago humingi ng download link

Maaaring sabihin ng bawat pinapanatiling channel kung ano ang i-install nito ngayon. Patakbuhin ang query sa target na makina, kasama ang mga repository na talagang ginagamit nito, bago isaalang-alang ang anumang paglilipat ng file.

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

Ang linyang kandidato na may bersyon at pangalan ng repository ay nangangahulugang mayroon nang build ang distribusyon para sa system na ito. Walang kandidato, o kandidato mula sa suite na hindi mo sinadyang gamitin, ay impormasyon tungkol sa iyong mga pinagmumulan, hindi tungkol sa kung umiiral ang software saanman.

Kung nabigo ang pag-refresh ng metadata, panatilihing hiwalay ang kabiguang iyon sa tanong ng package. Ang resolusyon ng pangalan, transportasyon ng repository, nawawalang Release signature at suite na nasa dulo ng buhay nito ay lahat nagbabasag ng apt update bago pa maisangkot ang kliyente. Ang pag-aayos ng mga pinagmumulan ay ibang gawain kaysa pagpili ng VPN client, at ang paghahalo ng dalawa ay kung paano nauuwi ang mga tao sa pagturo ng kasalukuyang system sa isang lumang release.

Ano ang bineberipika ng apt, at ano ang hindi nakukuha ng na-download na file

Ang normal na pag-install ay sumusunod sa isang chain ng mga lagda: nilalagdaan ng archive ang index nito, nagdadala ang index ng mga hash para sa bawat package, at dapat tumugma ang package. Inihihiwalay ng sanggunian ng authentication ng archive ang chain na iyon mula sa ideya ng pagsuri ng lagda na nakakabit sa bawat indibidwal na file.

Ang file na na-save mula sa lumang HTTP link ay wala ni isa sa mga iyon. Dumarating ito nang walang pagkakakilanlan ng repository, hindi ito naa-update kapag pinapatch ng distribusyon ang kliyente, at walang nagtatala kung sino ang may pananagutan sa pagpapalit nito. Maaari pa rin itong maging lehitimong pagpipilian para sa isang administrator na may naka-pin na artifact, ngunit ang pagpipilian ay dapat may kasamang may-ari, checksum na naitala saanman at plano para sa susunod na update sa seguridad.

Ang pagsugpo sa mga error sa lagda o pag-disable ng TLS verification upang patuloy na gumana ang lumang tagubilin ay nag-aalis ng tanging bahagi ng proseso na may sinusuri. Ibalik sa halip ang pagsusuring nabibigo.

I-install ang kliyente, pagkatapos i-debug nang hiwalay ang koneksyon

Kapag may pinapanatiling kandidato, i-install ito sa pamamagitan ng normal na na-review na transaksyon at hayaang itala ng package manager ang ginawa nito.

Kung talagang kailangan ng deployment ang isang build mula sa upstream, sundin ang kasalukuyang mga tagubilin sa pagbuo ng proyekto at ituring itong software na pinapanatili mo na ngayon: ang mga development package, pkg-config, ang mga header ng TLS library at ang PPP daemon ay tunay na dependency, gayundin ang pamamaraan ng pag-alis na kakailanganin mo mamaya.

Ang pag-install ay ang lokal na yugto ng software lamang. Kailangang tanggapin ng gateway ang protocol at daloy ng authentication ng kliyente, kailangang magtiwala ang kliyente sa certificate na ipinapakita ng gateway, at kailangan ng tunnel ang gumaganang PPP layer kasama ang mga ruta at may-ari ng resolver. Ang natapos na transaksyon ng package ay walang pinapatunayan tungkol sa kung tinatanggap ng gateway ang account o kung maaabot ang pribadong hanay. Subukan ang bawat layer sa lugar kung saan ito nasisira sa halip na muling patakbuhin ang installer.

Ang planong dapat pumalit sa lumang filename

Isulat muna ang pagkakakilanlan ng platform: release ng OS, arkitektura at ang listahan ng pinagmumulang ginagamit. Pagkatapos ay pangalanan ang awtorisadong lugar kung saan nagmumula ang package, maging repository ng distribusyon, repository ng vendor na may naka-pin na key o build na ikaw mismo ang nagko-compile at nagpa-package.

Panghuli, pangalanan ang tagapangalaga at ang landas ng update. Ang Pi na nagpapatakbo ng kliyenteng walang may-ari ay patuloy na gagana hanggang sa unang update ng library, at pagkatapos ay muling hahanapin ng isang taong may parehong problema ang parehong thread sa forum.

Ang itinamang paniniwala ay sapat na simple upang sabihin sa isang linya: ang lumang package ay ebidensya na minsang binuo at tumakbo ang kliyente, hindi ebidensya na mai-install ito sa iyong board ngayong gabi. Suriin ang tatlong axis, pagkatapos ay pumili ng channel na maaari mong patuloy na i-update.