Apt-opdatering misluk met NO_PUBKEY nadat ’n VPN-bron bygevoeg is

Jou VPN-verskaffer se apt-bron het jou pakketbestuurder gebreek, en die oplossing is ’n besluit eerder as ’n opdrag. NO_PUBKEY, of ’n klag dat die bewaarplek geen Release-lêer het nie, beteken apt het geweier om daardie bron te vertrou, so elke latere pakketbewerking bly dieselfde waarskuwing druk. Die tonnel self is waarskynlik onskuldig. Beantwoord drie vrae oor of jy daardie bron nog wil hê, en die korrekte herstel volg byna meganies.

Eerstens: plaas die fout in die regte kategorie

’n Vertrouefout noem die bronlêer en óf die ontbrekende sleutel óf die afwesige Release-lêer. ’n Vervoerfout lyk anders: TLS-sertifikaatfoute, verbinding geweier, tydsverstryking, of ’n proxy wat CONNECT weier. Daardie onderskeid bepaal watter artikel jy lees, want ’n VPN wat TLS onderskep of die verskaffer se gasheer blokkeer, lewer vervoerfoute, nie handtekeningfoute nie.

Voer sudo apt update alleen uit en lees die stert, terwyl jy die gekaste treffers hierbo ignoreer. Die reël wat saak maak, noem /etc/apt/sources.list.d/ en sê vir jou watter lêer om oop te maak.

As die fout volg wanneer die tonnel opkom, toets met die tonnel af en met DNS wat deur die stelsel se oplosser opgelos word. ’n Bron wat sonder die VPN werk, is ’n roeterings- of onderskeppingskwessie, en geen hoeveelheid sleutelbestuur sal dit regstel nie.

Drie vrae wat die pad kies

Installeer of gradeer jy nog pakkette vanaf hierdie bron op? As die kliënt aktief gebruik word, herstel die vertroue. As jy die kliënt een keer geïnstalleer het en nou ’n gewone profiel in NetworkManager invoer, is die bron dooie gewig en is verwydering die eerlike oplossing.

Tweedens: publiseer die verskaffer ’n sleutel en ’n vingerafdruk wat jy buite die kanaal kan verifieer? Derdens: wie bestuur sleutels op hierdie gasheer, die verspreiding of jy? ’n Bron wat deur ’n sleutel onderteken is wat jy nie kan verifieer nie, is ’n opdateringsgesag wat jy nie behoort toe te staan nie.

Om nee op die eerste vraag te antwoord, beëindig die ontleding. Om ja op al drie punte te antwoord, wys na die signed-by-herstel, die enigste reëling wat beide werk en ouditeerbaar bly. Om die twee paaie te meng deur die bron te hou en dit deur te dwing, is die een opsie wat die moeite werd is om uitdruklik uit te sluit.

Waarom trusted=yes soos ’n oplossing lyk en tog nie een is nie

Die handleidingblad vir sources.list is reguit daaroor. Om die Trusted-opsie op yes te stel, sê vir apt om die bron te aanvaar selfs wanneer dit verifikasie misluk, wat apt-secure vir daardie bewaarplek afskakel. Die bladsy hou dit vir ’n plaaslike konteks, as dit hoegenaamd gebruik word.

Dit is nie ’n smaller weergawe van vertroue in die verskaffer nie. Dit verwyder die vraag oor wie die indeks onderteken het, so enigiemand wat vir daardie gasheernaam kan antwoord, kan vir jou masjien pakkette gee wat as root installeer.

Herstelpad: haal die sleutel en pen dit dan vas

Haal die sleutel by die plek wat die verskaffer dokumenteer en dearmer dit in ’n sleutelring wat deur die administrateur bestuur word, en rig dan die bewaarplekreël na daardie lêer sodat die vertroue nie kan wegdryf nie.

1. Lees die falende reël om die sleutel-ID en die bronlêernaam te kry.
2. Laai die verskaffer se ASCII-gepantserde sleutel af en voer gpg --dearmor uit na /etc/apt/keyrings/vendor-name.gpg.
3. Voeg [signed-by=/etc/apt/keyrings/vendor-name.gpg] by die inskrywing in daardie verskaffer se .list-lêer.
4. Voer sudo apt update uit en bevestig dat die bron ’n indeks haal eerder as om die handtekeningwaarskuwing te herhaal.

Verkies /usr/share/keyrings vir sleutels wat saam met ’n pakket kom en /etc/apt/keyrings vir sleutels wat jy met die hand plaas. Die splitsing is nie kosmeties nie: dit sê vir die volgende administrateur watter sleutels ’n pakketopgradering sal oorleef en watter een ’n mens nodig het.

Verifieer die vingerafdruk teen die verskaffer se gepubliseerde waarde voordat jy dit vertrou. ’n Sleutel-ID wat uit ’n forumpos geplak is, is hoe ’n masjien ’n opdateringsgesag begin vertrou wat niemand kan noem nie.

Verwyderingspad, en waarom die fout kan terugkom

Kyk wat die installeerder werklik geskryf het, want verskeie lêers kan dieselfde verskaffer noem en een daarvan is gewoonlik ’n oorblywende kopie.

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

apt lees net .list en .sources-lêers uit daardie gids, so ’n .save of .distUpgrade-kopie word reeds geïgnoreer; om dit tog te verwyder, keer dat ’n latere leser dit per ongeluk herstel. Om die bron te verwyder, deïnstalleer niks, en apt kan dan die geïnstalleerde VPN-pakket beskryf as plaaslik geïnstalleer of nie meer beskikbaar nie, wat ’n pakketstatusboodskap is eerder as die terugkeer van die vertrouefout.

Die herhalende geval is ouer leiding wat sleutels met apt-key in die globale vertroude ring geïnstalleer het. Daardie pad is verouderd, en ’n vrystellingsopgradering kan die sleutel laat val of bloot ongeraadpleeg laat, wat presies is waarom ’n fout wat ’n jaar lank stil was, in die week van jou opgradering verskyn. Gaan /etc/apt/trusted.gpg.d/ na en skuif dan die vertrouebesluit na die bewaarplekreël waar dit hoort. As die verskaffer nog apt-key-instruksies druk, gebruik eerder signed-by; dit is die reëling wat die handleiding dokumenteer, en dit is die een wat ’n opgradering oorleef.