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; тоа е распоредот што го документира прирачникот, и оној што преживува надградба.

Поврзани статии