apt atnaujinimas nepavyksta su NO_PUBKEY pridėjus VPN saugyklą

Jūsų VPN tiekėjo apt šaltinis sugadino paketų tvarkyklę, o pataisymas yra sprendimas, ne komanda. NO_PUBKEY, arba skundas, kad saugykla neturi Release failo, reiškia, kad apt atsisakė pasitikėti tuo šaltiniu, todėl kiekviena vėlesnė paketų operacija toliau spausdina tą patį įspėjimą. Pats tunelis tikriausiai nekaltas. Atsakykite į tris klausimus, ar vis dar norite to šaltinio, ir teisingas taisymas ateina beveik mechaniškai.

Pirma, įdėkite gedimą į teisingą kategoriją

Pasitikėjimo gedimas įvardija šaltinio failą ir arba trūkstamą raktą, arba nesančio Release failo. Perdavimo gedimas atrodo kitaip: TLS sertifikato klaidos, atmestas ryšys, laiko limitai arba tarpinis serveris, atmetantis CONNECT. Šis skirtumas nulemia, kurį straipsnį skaitote, nes VPN, perimantis TLS ar blokuojantis tiekėjo mazgą, sukuria perdavimo, o ne parašo klaidas.

Paleiskite sudo apt update vieną ir perskaitykite pabaigą, ignoruodami podėlyje esančius rezultatus viršuje. Svarbi eilutė įvardija /etc/apt/sources.list.d/ ir pasako, kurį failą atidaryti.

Jei gedimas atsiranda pakilus tuneliui, bandykite su išjungtu tuneliu ir su DNS, sprendžiamu sistemos sprendiklio. Šaltinis, veikiantis be VPN, yra maršrutizavimo ar perėmimo klausimas, ir jokia raktų valdymo priemonė to neištaisys.

Trys klausimai, kurie pasirenka kelią

Ar vis dar diegiate ar atnaujinate paketus iš šio šaltinio? Jei klientas aktyviai naudojamas, sutaisykite pasitikėjimą. Jei klientą įdiegėte kartą ir dabar importuojate paprastą profilį į NetworkManager, šaltinis yra nereikalingas balastas, o pašalinimas yra sąžiningas pataisymas.

Antra, ar tiekėjas skelbia raktą ir piršto atspaudą, kuriuos galite patikrinti ne kanalu? Trečia, kas valdo raktus šiame mazge: distribucija ar jūs? Šaltinis, pasirašytas raktu, kurio negalite patikrinti, yra atnaujinimo įgaliojimas, kurio neturėtumėte suteikti.

Ne į pirmą klausimą baigia analizę. Taip į visus tris punktus veda prie signed-by taisymo, vienintelės tvarkos, kuri ir veikia, ir išlieka audituojama. Abiejų kelių maišymas, paliekant šaltinį ir jį priverstinai prakišant, yra vienintelė galimybė, kurią verta aiškiai atmesti.

Kodėl trusted=yes atrodo kaip pataisymas, bet nėra

Puslapis sources.list vadove tai sako tiesiogiai. Parinktį Trusted nustačius į yes apt priims šaltinį net ir nepavykus autentifikacijai, o tai išjungia apt-secure tai saugyklai. Puslapis tai palieka vietinei aplinkai, jei apskritai naudojama.

Tai ne siauresnė pasitikėjimo tiekėju versija. Tai pašalina klausimą, kas pasirašė indeksą, todėl bet kas, kas gali atsakyti už tą mazgo vardą, gali duoti jūsų mašinai paketus, kurie įdiegiami kaip root.

Taisymo kelias: gaukite raktą, tada jį prisekite

Gaukite raktą iš vietos, kurią dokumentuoja tiekėjas, ir išpakuokite jį į administratoriaus valdomą raktų rinkinį, tada nukreipkite saugyklos eilutę į tą failą, kad pasitikėjimas negalėtų nuslysti.

1. Perskaitykite nepavykstančią eilutę, kad gautumėte rakto ID ir šaltinio failo pavadinimą.
2. Atsisiųskite tiekėjo ASCII šarvuotą raktą ir paleiskite gpg --dearmor į /etc/apt/keyrings/vendor-name.gpg.
3. Pridėkite [signed-by=/etc/apt/keyrings/vendor-name.gpg] prie to tiekėjo .list failo įrašo.
4. Paleiskite sudo apt update ir patvirtinkite, kad šaltinis gauna indeksą, o ne kartoja parašo įspėjimą.

Teikite pirmenybę /usr/share/keyrings raktams, kurie ateina su paketu, ir /etc/apt/keyrings raktams, kuriuos dedate rankiniu būdu. Šis atskyrimas nėra kosmetinis: jis pasako kitam administratoriui, kurie raktai išgyvens paketo atnaujinimą, o kuriems reikia žmogaus.

Patikrinkite piršto atspaudą su paskelbta tiekėjo verte prieš juo pasitikėdami. Rakto ID, įklijuotas iš forumo įrašo, yra būdas, kuriuo mašina pradeda pasitikėti atnaujinimo įgaliojimu, kurio niekas negali įvardyti.

Pašalinimo kelias ir kodėl klaida gali grįžti

Pažiūrėkite, ką diegėjas iš tikrųjų įrašė, nes keli failai gali minėti tą patį tiekėją, ir vienas jų paprastai yra likusi kopija.

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

apt iš to katalogo skaito tik .list ir .sources failus, todėl .save arba .distUpgrade kopija jau ignoruojama; vis dėlto ją ištrynus vėlesnis skaitytojas negalės jos atsitiktinai atkurti. Šaltinio pašalinimas nieko nepašalina, ir apt tuomet gali apibūdinti įdiegtą VPN paketą kaip vietiškai įdiegtą arba nebeprieinamą, o tai yra paketo būsenos pranešimas, ne pasitikėjimo klaidos sugrįžimas.

Pasikartojantis atvejis yra senesnė instrukcija, kuri raktus įdiegė su apt-key į pasaulinį patikimą žiedą. Tas kelias pasenęs, o leidimo atnaujinimas gali palikti raktą numestą arba tiesiog nepaklaustą, ir būtent todėl metus tylėjusi klaida pasirodo tą savaitę, kai atnaujinate. Patikrinkite /etc/apt/trusted.gpg.d/, tada perkelkite pasitikėjimo sprendimą į saugyklos eilutę, kur jam vieta. Jei tiekėjas vis dar spausdina apt-key instrukcijas, vis tiek naudokite signed-by; tai tvarka, kurią dokumentuoja vadovas, ir ta, kuri išgyvena atnaujinimą.