apt-ի թարմացումը ձախողվում է NO_PUBKEY-ով VPN պահոցն ավելացնելուց հետո

NO_PUBKEY-ն և բացակայող Release ֆայլը վստահության խափանումներ են, ոչ ցանցային։ Որոշեք՝ ամրացնե՞լ մատակարարի բանալին signed-by-ով, թե՞ հեռացնել աղբյուրը։

Ձեր VPN մատակարարի apt աղբյուրը կոտրել է փաթեթների կառավարիչը, և ուղղումը որոշում է, ոչ հրաման։ NO_PUBKEY, կամ բողոք, որ պահոցը Release ֆայլ չունի, նշանակում է, որ apt-ը հրաժարվել է վստահել այդ աղբյուրին, ուստի յուրաքանչյուր հետագա փաթեթային գործողություն շարունակում է տպել նույն զգուշացումը։ Թունելն ինքը, հավանաբար, անմեղ է։ Պատասխանեք երեք հարցի՝ արդյոք դեռ ուզում եք այդ աղբյուրը, և ճիշտ վերանորոգումը գալիս է գրեթե մեխանիկորեն։

Նախ՝ դրեք խափանումը ճիշտ կատեգորիայի մեջ

Վստահության խափանումը նշում է աղբյուրի ֆայլը և կամ բացակայող բանալին, կամ բացակայող Release ֆայլը։ Տրանսպորտի խափանումն այլ տեսք ունի՝ TLS վկայագրի սխալներ, մերժված միացում, ժամկետի լրանալու սխալներ, կամ CONNECT-ը մերժող պրոքսի։ Այս տարբերությունը որոշում է, թե որ հոդվածն եք կարդում, որովհետև TLS-ը ընդհատող կամ մատակարարի հոսթը արգելափակող VPN-ը տրանսպորտի սխալներ է առաջացնում, ոչ ստորագրության սխալներ։

Գործարկեք 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. դա այն կարգավորումն է, որը փաստաթղթավորում է ձեռնարկը, և այն, որը դիմանում է թարմացմանը։

Առնչվող հոդվածներ