Nabibigo ang pag-update ng apt gamit ang NO_PUBKEY matapos magdagdag ng VPN repository

Sinira ng apt source ng iyong VPN vendor ang package manager, at ang solusyon ay isang desisyon, hindi isang utos. NO_PUBKEY, o isang reklamong walang Release file ang repository, ay nangangahulugang tumanggi ang apt na magtiwala sa source na iyon, kaya patuloy na ipinapasa-print ng bawat susunod na operasyon ng package ang parehong babala. Ang tunnel mismo ay malamang walang kasalanan. Sagutin ang tatlong tanong kung gusto pa rin ang source na iyon, at ang tamang pag-aayos ay halos mekanikal na sumusunod.

Una, ilagay ang kabiguan sa tamang kategorya

Pinapangalanan ng kabiguan ng tiwala ang source file at alinman sa nawawalang susi o sa nawawalang Release file. Iba ang hitsura ng kabiguan ng transport: mga error sa TLS certificate, tinanggihang koneksyon, mga timeout, o isang proxy na tumatanggi sa CONNECT. Ang pagkakaibang iyon ang nagtatakda kung aling artikulo ang binabasa mo, dahil ang VPN na humaharang sa TLS o nagboblock sa host ng vendor ay gumagawa ng mga error sa transport, hindi error sa pirma.

Patakbuhin ang sudo apt update nang mag-isa at basahin ang dulo, habang binabalewala ang mga naka-cache na resulta sa itaas. Ang linyang mahalaga ay nagpapangalan ng /etc/apt/sources.list.d/ at nagsasabi kung aling file ang bubuksan.

Kung ang kabiguan ay sumusunod sa pag-angat ng tunnel, subukan nang nakababa ang tunnel at nang naresolba ang DNS sa resolver ng system. Ang source na gumagana nang walang VPN ay isyu ng routing o interception, at walang anumang pamamahala ng susi ang makakaayos nito.

Tatlong tanong na pumipili ng landas

Nag-i-install o nag-a-upgrade ka pa ba ng mga package mula sa source na ito? Kung aktibong ginagamit ang client, ayusin ang tiwala. Kung isang beses mong na-install ang client at ngayon ay nag-aangkat ka ng ordinaryong profile sa NetworkManager, ang source ay patay na bigat at ang pag-alis nito ang tapat na pag-aayos.

Pangalawa, naglalathala ba ang vendor ng susi at fingerprint na maaari mong i-verify sa labas ng channel? Pangatlo, sino ang namamahala ng mga susi sa host na ito: ang distribution o ikaw? Ang source na pinirmahan ng susing hindi mo ma-verify ay awtoridad sa pag-update na hindi mo dapat ibigay.

Ang sagot na hindi sa unang tanong ay nagtatapos sa pagsusuri. Ang sagot na oo sa lahat ng tatlong punto ay tumuturo sa pag-aayos gamit ang signed-by, ang tanging kaayusan na gumagana at nananatiling madaling suriin. Ang paghahalo ng dalawang landas, sa pamamagitan ng pagpapanatili ng source at pagpilit dito, ang tanging opsyon na sulit na tahasang ibukod.

Bakit mukhang pag-aayos ang trusted=yes at hindi naman

Ang pahina ng manwal ng sources.list ay tuwiran tungkol dito. Ang pagtakda ng opsyon na Trusted sa yes ay nagsasabi sa apt na tanggapin ang source kahit nabigo ang authentication, na nagpapatay ng apt-secure para sa repository na iyon. Inilalaan ito ng pahina para sa lokal na konteksto, kung gagamitin man.

Hindi ito mas makitid na bersyon ng pagtitiwala sa vendor. Inaalis nito ang tanong kung sino ang pumirma sa index, kaya sinumang makasagot para sa hostname na iyon ay makakapagbigay sa iyong makina ng mga package na naka-install bilang root.

Landas ng pag-aayos: kunin ang susi, pagkatapos ay ikabit ito

Kunin ang susi mula sa lokasyong dokumentado ng vendor at ilabas ito sa isang keyring na pinamamahalaan ng administrator, pagkatapos ay ituro ang linya ng repository sa file na iyon upang hindi makalihis ang tiwala.

1. Basahin ang linyang nabibigo upang makuha ang ID ng susi at ang pangalan ng source file.
2. I-download ang ASCII-armoured na susi ng vendor at patakbuhin ang gpg --dearmor papunta sa /etc/apt/keyrings/vendor-name.gpg.
3. Idagdag ang [signed-by=/etc/apt/keyrings/vendor-name.gpg] sa entry sa file na .list ng vendor na iyon.
4. Patakbuhin ang sudo apt update at kumpirmahin na kumukuha ng index ang source sa halip na ulitin ang babala sa pirma.

Mas gusto ang /usr/share/keyrings para sa mga susing kasama ng package at /etc/apt/keyrings para sa mga susing inilalagay mo nang manwal. Hindi kosmetiko ang paghahati: sinasabi nito sa susunod na administrator kung aling mga susi ang makakaligtas sa pag-upgrade ng package at alin ang kailangan ng tao.

I-verify ang fingerprint laban sa inilathalang halaga ng vendor bago ito pagkatiwalaan. Ang ID ng susing idinikit mula sa post sa forum ang paraan kung paano nagsisimulang magtiwala ang isang makina sa awtoridad sa pag-update na walang makapagpangalan.

Landas ng pag-alis, at bakit maaaring bumalik ang error

Tingnan kung ano talaga ang isinulat ng installer, dahil maraming file ang maaaring magbanggit ng parehong vendor at ang isa sa kanila ay karaniwang natirang kopya.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

Binabasa lamang ng apt ang mga file na .list at .sources mula sa direktoryo na iyon, kaya ang kopyang .save o .distUpgrade ay binabalewala na; gayunman, ang pagtanggal nito ay pumipigil sa susunod na mambabasa na maibalik ito nang aksidente. Ang pag-alis ng source ay walang tinatanggal na naka-install, at maaaring ilarawan ng apt ang naka-install na VPN package bilang lokal na naka-install o hindi na available, na mensahe ng estado ng package at hindi ang pagbabalik ng error sa tiwala.

Ang paulit-ulit na kaso ay mas lumang gabay na nag-install ng mga susi gamit ang apt-key sa pandaigdigang trusted ring. Lipas na ang landas na iyon, at ang pag-upgrade ng release ay maaaring mag-iwan sa susi na nahulog o hindi lang kinonsulta, at iyon ang dahilan kung bakit ang error na tahimik nang isang taon ay lumalabas sa linggong nag-a-upgrade ka. Suriin ang /etc/apt/trusted.gpg.d/, pagkatapos ay ilipat ang desisyon sa tiwala sa linya ng repository kung saan ito nararapat. Kung nagpi-print pa rin ang vendor ng mga tagubilin sa apt-key, gamitin pa rin ang signed-by; ito ang kaayusang dokumentado ng manwal, at ito ang nakakaligtas sa isang pag-upgrade.