VPN റിപ്പോസിറ്ററി ചേർത്തതിന് ശേഷം NO_PUBKEY-യോടെ apt അപ്ഡേറ്റ് പരാജയപ്പെടുന്നു

നിങ്ങളുടെ 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 ഉപയോഗിക്കുക; അതാണ് മാനുവൽ രേഖപ്പെടുത്തുന്ന ക്രമീകരണം, അപ്ഗ്രേഡ് അതിജീവിക്കുന്നതും അതാണ്.