apt ажурирање не успева са NO_PUBKEY након додавања VPN репозиторијума

NO_PUBKEY и недостајућа Release датотека су грешке поверења, а не мрежни кварови. Одлучите да ли ћете приквачити кључ добављача помоћу signed-by или уклонити извор.

apt извор вашег VPN добављача покварио је ваш управљач пакета, а поправка је одлука, а не наредба. NO_PUBKEY, или притужба да репозиторијум нема Release датотеку, значи да је apt одбио да верује том извору, па свака каснија операција са пакетима наставља да исписује исто упозорење. Сам тунел је вероватно недужан. Одговорите на три питања о томе да ли вам је тај извор и даље потребан, и исправна поправка следи готово механички.

Најпре сместите квар у праву категорију

Грешка поверења именује датотеку извора и или кључ који недостаје или одсутну Release датотеку. Грешка преноса изгледа другачије: грешке TLS сертификата, одбијена веза, истеци времена или прокси који одбија CONNECT. Та разлика одлучује који чланак читате, јер VPN који пресреће TLS или блокира хост добављача производи грешке преноса, а не грешке потписа.

Покрените sudo apt update самостално и прочитајте крај, занемарујући кеширане поготке изнад. Линија која је важна именује /etc/apt/sources.list.d/ и говори вам коју датотеку да отворите.

Ако се квар јавља након подизања тунела, тестирајте са искљученим тунелом и са DNS-ом који разрешава системски резолвер. Извор који ради без VPN-а је питање усмеравања или пресретања, и никакво управљање кључевима то неће поправити.

Три питања која бирају пут

Да ли још увек инсталирате или надграђујете пакете из овог извора? Ако је клијент у активној употреби, поправите поверење. Ако сте клијент инсталирали једном и сада увозите обичан профил у NetworkManager, извор је мртав терет и уклањање је искрена поправка.

Друго, да ли добављач објављује кључ и отисак који можете проверити изван канала? Треће, ко управља кључевима на овом хосту: дистрибуција или ви? Извор потписан кључем који не можете проверити јесте овлашћење за ажурирање које не бисте требали дати.

Одговор не на прво питање завршава анализу. Одговор да на све три тачке упућује на поправку помоћу signed-by, једини распоред који и ради и остаје ревидиран. Мешање два пута, задржавањем извора и насилним прогуравањем, једина је опција коју вреди изричито искључити.

Зашто trusted=yes изгледа као поправка, а није

Страница приручника за sources.list је изричита о томе. Постављање опције Trusted на yes каже apt-у да прихвати извор чак и када не прође аутентификацију, што искључује apt-secure за тај репозиторијум. Страница то задржава за локални контекст, ако се уопште користи.

То није ужа верзија поверења у добављача. Тиме се уклања питање ко је потписао индекс, па свако ко може да одговори за то име хоста може вашем рачунару дати пакете који се инсталирају као root.

Пут поправке: набавите кључ, затим га приквачите

Набавите кључ са места које добављач документује и распакујте га у привезак кључева којим управља администратор, затим усмерите линију репозиторијума на ту датотеку како поверење не би могло да одлута.

  1. Прочитајте линију која не успева да бисте добили ID кључа и назив датотеке извора.
  2. Преузмите добављачев ASCII-оклопљени кључ и покрените gpg --dearmor у /etc/apt/keyrings/vendor-name.gpg.
  3. Додајте [signed-by=/etc/apt/keyrings/vendor-name.gpg] уносу у датотеци .list тог добављача.
  4. Покрените sudo apt update и потврдите да извор дохвата индекс уместо да понавља упозорење о потпису.

Дајте предност /usr/share/keyrings за кључеве који долазе са пакетом и /etc/apt/keyrings за кључеве које постављате ручно. Та подела није козметичка: говори следећем администратору који ће кључеви преживети надоградњу пакета, а који траже човека.

Проверите отисак према добављачевој објављеној вредности пре него што му поверујете. ID кључа залепљен са форума је начин на који рачунар почне да верује овлашћењу за ажурирање које нико не може да именује.

Пут уклањања и зашто се грешка може вратити

Погледајте шта је инсталатер заиста записао, јер неколико датотека може да спомене истог добављача и једна од њих је обично заостала копија.

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

apt чита само датотеке .list и .sources из тог директоријума, па се копија .save или .distUpgrade већ занемарује; брисање ипак спречава каснијег читаоца да је случајно врати. Уклањање извора не деинсталира ништа, а apt тада може да опише инсталирани VPN пакет као локално инсталиран или више недостапан, што је порука о стању пакета, а не повратак грешке поверења.

Случај који се понавља су старија упутства која су инсталирала кључеве помоћу apt-key у глобални прстен поверења. Тај пут је застарео, а надоградња издања може да остави кључ испуштеним или једноставно неконсултованим, и управо зато се грешка која је годину дана била тиха појављује у недељи ваше надоградње. Проверите /etc/apt/trusted.gpg.d/, затим преместите одлуку о поверењу у линију репозиторијума где јој је место. Ако добављач још исписује упутства за apt-key, ипак употребите signed-by; то је распоред који приручник документује и онај који преживљава надоградњу.

Повезани чланци