Përditësimi me apt dështon me NO_PUBKEY pas shtimit të një depoje VPN

Burimi apt i ofruesit tuaj të VPN ka prishur menaxherin e paketave, dhe rregullimi është një vendim, jo një komandë. NO_PUBKEY, ose një ankesë se depoja nuk ka skedar Release, do të thotë që apt refuzoi të besonte atë burim, kështu që çdo operacion i mëvonshëm me paketa vazhdon të printojë të njëjtin paralajmërim. Vetë tuneli është ndoshta i pafajshëm. Përgjigjuni tre pyetjeve nëse ende e dëshironi atë burim, dhe rregullimi i saktë vjen pothuajse mekanikisht.

Së pari, vendoseni dështimin në kategorinë e duhur

Një dështim besimi emërton skedarin e burimit dhe ose çelësin që mungon ose skedarin Release që mungon. Një dështim transporti duket ndryshe: gabime certifikate TLS, lidhje e refuzuar, skadime kohe ose një proxy që refuzon CONNECT. Ky dallim vendos se cilin artikull po lexoni, sepse një VPN që përgjon TLS ose bllokon hostin e ofruesit prodhon gabime transporti, jo gabime nënshkrimi.

Ekzekutoni sudo apt update vetëm dhe lexoni fundin, duke injoruar rezultatet e ruajtura në cache sipër. Rreshti që ka rëndësi emërton /etc/apt/sources.list.d/ dhe ju tregon cilin skedar të hapni.

Nëse dështimi vjen pas ngritjes së tunelit, provoni me tunelin të ulur dhe me DNS të zgjidhur nga zgjidhësi i sistemit. Një burim që funksionon pa VPN është çështje rrugëtimi ose përgjimi, dhe asnjë sasi e menaxhimit të çelësave nuk e rregullon atë.

Tre pyetje që zgjedhin rrugën

A po instaloni ose përditësoni ende paketa nga ky burim? Nëse klienti është në përdorim aktiv, rregulloni besimin. Nëse e keni instaluar klientin një herë dhe tani importoni një profil të zakonshëm në NetworkManager, burimi është peshë e vdekur dhe heqja është rregullimi i ndershëm.

Së dyti, a publikon ofruesi një çelës dhe një gjurmë gishti që mund t'i verifikoni jashtë kanalit? Së treti, kush i menaxhon çelësat në këtë host: shpërndarja apo ju? Një burim i nënshkruar me një çelës që nuk mund ta verifikoni është autoritet përditësimi që nuk duhet ta jepni.

Një jo në pyetjen e parë e përfundon analizën. Një po në të tre pikat çon te rregullimi me signed-by, i vetmi rregullim që funksionon dhe mbetet i auditueshëm. Përzierja e dy rrugëve, duke e mbajtur burimin dhe duke e shtyrë me forcë, është opsioni i vetëm që ia vlen të përjashtohet në mënyrë eksplicite.

Pse trusted=yes duket si rregullim dhe nuk është

Faqja e manualit të sources.list është e drejtpërdrejtë për këtë. Vendosja e opsionit Trusted në yes i thotë apt-it ta pranojë burimin edhe kur dështon autentikimi, gjë që fik apt-secure për atë depo. Faqja e rezervon atë për një kontekst lokal, nëse përdoret fare.

Ky nuk është një version më i ngushtë i besimit te ofruesi. Ai e heq pyetjen se kush e nënshkroi indeksin, kështu që kushdo që mund të përgjigjet për atë emër hosti mund t'i japë makinës tuaj paketa që instalohen si root.

Rruga e rregullimit: merrni çelësin, pastaj fiksojeni

Merrni çelësin nga vendi që dokumenton ofruesi dhe shpaketojeni në një rreth çelësash të menaxhuar nga administratori, pastaj drejtojeni rreshtin e depos te ai skedar që besimi të mos rrëshqasë.

1. Lexoni rreshtin që dështon për të marrë ID-në e çelësit dhe emrin e skedarit të burimit.
2. Shkarkoni çelësin e ofruesit të blinduar në ASCII dhe ekzekutoni gpg --dearmor në /etc/apt/keyrings/vendor-name.gpg.
3. Shtoni [signed-by=/etc/apt/keyrings/vendor-name.gpg] te zëri në skedarin .list e atij ofruesi.
4. Ekzekutoni sudo apt update dhe konfirmoni se burimi merr një indeks në vend që të përsërisë paralajmërimin e nënshkrimit.

Preferoni /usr/share/keyrings për çelësat që vijnë me një paketë dhe /etc/apt/keyrings për çelësat që i vendosni me dorë. Kjo ndarje nuk është kozmetike: i thotë administratorit të ardhshëm cilët çelësa do t'i mbijetojnë një përditësimi pakete dhe cilët kanë nevojë për një njeri.

Verifikoni gjurmën e gishtit kundrejt vlerës së publikuar të ofruesit përpara se t'i besoni. Një ID çelësi i ngjitur nga një postim forumi është mënyra se si një makinë fillon të besojë një autoritet përditësimi që askush nuk mund ta emërtojë.

Rruga e heqjes, dhe pse gabimi mund të kthehet

Shikoni çfarë shkroi vërtet instaluesi, sepse disa skedarë mund të përmendin të njëjtin ofrues dhe njëri prej tyre është zakonisht një kopje e mbetur.

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

apt lexon vetëm skedarë .list dhe .sources nga ai direktorium, kështu që një kopje .save ose .distUpgrade tashmë injorohet; fshirja e saj gjithsesi pengon një lexues të mëvonshëm ta rivendosë aksidentalisht. Heqja e burimit nuk çinstalon asgjë, dhe apt mund ta përshkruajë më pas paketën VPN të instaluar si të instaluar lokalisht ose si jo më të disponueshme, që është një mesazh i gjendjes së paketës dhe jo kthimi i gabimit të besimit.

Rasti i përsëritur është udhëzim më i vjetër që instalonte çelësat me apt-key në unazën globale të besimit. Ajo rrugë është e vjetëruar, dhe një përditësim i versionit mund ta lërë çelësin të rënë ose thjesht të pakonsultuar, dhe pikërisht për këtë një gabim që ishte i qetë për një vit shfaqet në javën kur përditësoni. Kontrolloni /etc/apt/trusted.gpg.d/, pastaj zhvendosni vendimin e besimit në rreshtin e depos ku i takon. Nëse ofruesi ende printon udhëzime apt-key, përdorni gjithsesi signed-by; është rregullimi që dokumenton manuali, dhe ai që i mbijeton një përditësimi.