apt-cache നിങ്ങളുടെ VPN പാക്കേജിനായി ഇൻസ്റ്റാൾ ചെയ്തത് (ഒന്നുമില്ല) എന്ന് കാണിക്കുന്നത് എന്തുകൊണ്ട്

Installed: (none) എന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന VPN പാക്കേജ് കാണാതെ പോയതല്ല; അത് ഇൻസ്റ്റാൾ ചെയ്തിട്ടില്ല എന്ന് മാത്രം. ഇത് ഇൻസ്റ്റാൾ ചെയ്യാനാകുമോ എന്ന് തീരുമാനിക്കുന്ന വരിയാണ് Candidate, അത് APT ഇൻഡക്സുകൾ, suite നാമം, ആർക്കിടെക്ചർ, നിലവിലുള്ള ഏതെങ്കിലും പിൻ നിയമങ്ങൾ എന്നിവയിൽ നിന്ന് കണ്ടെത്തുന്നു. കാണാതായ VPN പാക്കേജിനെക്കുറിച്ചുള്ള മിക്ക റിപ്പോർട്ടുകളും പാക്കേജിംഗ് പ്രശ്നമല്ല, സ്ഥാനാർത്ഥി പ്രശ്നമാണെന്ന് തെളിയുന്നു. ഒരു ഉറവിട എൻട്രിയിൽ പോലും തൊടുന്നതിന് മുമ്പ് രണ്ട് വരികളും വായിക്കുക.

ഞാൻ ആദ്യം സ്ഥാനാർത്ഥി പരിശോധിക്കുന്നു, കാരണം അതിന് ഒരു കമാൻഡ് മാത്രം മതി, സാധാരണ ഊഹങ്ങളുടെ പകുതി ഒഴിവാക്കുകയും ചെയ്യുന്നു.

apt-cache policy-യുടെ ഔട്ട്പുട്ട് നിങ്ങളോട് പറയുന്നത്

apt-cache policy നെറ്റ്വർക്കല്ല, പ്രാദേശിക പാക്കേജ് കാഷെ വായിക്കുന്നു. ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പ്, സ്ഥാനാർത്ഥി പതിപ്പ്, പാക്കേജ് വാഗ്ദാനം ചെയ്യുന്ന ഓരോ ഇൻഡക്സിന്റെയും പട്ടിക അതിനോട് ബന്ധിപ്പിച്ച മുൻഗണനയോടെ അത് പ്രിന്റ് ചെയ്യുന്നു.

apt-cache policy openvpn
apt-cache madison openvpn
apt list -a network-manager-openvpn

APT ഇപ്പോൾ തിരഞ്ഞെടുക്കുന്ന പതിപ്പാണ് സ്ഥാനാർത്ഥി. madison ഓരോ ഉറവിടവും അതിന്റെ മുൻഗണനയോടെ എന്ത് വാഗ്ദാനം ചെയ്യുന്നു എന്ന് ലിസ്റ്റ് ചെയ്യുന്നു, അങ്ങനെയാണ് ഇൻഡക്സിൽ ഉണ്ടെങ്കിലും പിൻ മത്സരത്തിൽ തോൽക്കുന്ന പാക്കേജ് നിങ്ങൾ കണ്ടെത്തുന്നത്. apt-cache കൈപ്പുസ്തകം രണ്ടും കാഷെ വായനയായി രേഖപ്പെടുത്തുന്നു, അതിനാൽ ഇപ്പോൾ കണ്ണാടി ലഭ്യമാണെന്ന് രണ്ടും തെളിയിക്കുന്നില്ല.

സ്ഥാനാർത്ഥി വരി ശൂന്യമാണെങ്കിൽ അല്ലെങ്കിൽ (none) കാണിക്കുന്നുവെങ്കിൽ, കോൺഫിഗർ ചെയ്ത ഉറവിടങ്ങളിൽ ഈ സിസ്റ്റത്തിന്, അത് കോൺഫിഗർ ചെയ്തിരിക്കുന്നതുപോലെ, ഒന്നും യോഗ്യമല്ല.

സ്ഥാനാർത്ഥി അപ്രത്യക്ഷമാകാനുള്ള നാല് കാരണങ്ങൾ

പ്രായോഗികമായി കാരണം മിക്കവാറും എപ്പോഴും നാലിൽ ഒന്നാണ്, ഓരോന്നിനും വ്യത്യസ്ത പരിഹാരമുണ്ട്.

നിങ്ങളുടെ ഉറവിടങ്ങളിലെ suite നാമം പാക്കേജ് നിർമ്മിച്ച ഡിസ്ട്രിബ്യൂഷനുമായി പൊരുത്തപ്പെടണം. trixie കണ്ണാടിയിലേക്ക് ചൂണ്ടുന്ന Debian bookworm സിസ്റ്റം, അല്ലെങ്കിൽ അപ്ഗ്രേഡിനിടയിൽ sources.list.d ഫയലിൽ പേരുമാറ്റിയ Ubuntu പതിപ്പ്, മറ്റേ suite-ൽ മാത്രമുള്ള പാക്കേജുകൾക്ക് ഒന്നും പരിഹരിക്കുന്നില്ല. ഓരോ എൻട്രിയിലെയും suite ഫീൽഡുമായി lsb_release -cs താരതമ്യം ചെയ്യുക.

dpkg അറിയുന്ന ആർക്കിടെക്ചറുകൾക്കായി നിർമ്മിച്ച പാക്കേജുകൾ മാത്രമേ APT കാണുന്നുള്ളൂ. 32-ബിറ്റ് കണ്ടെയ്നർ, arm64 ഇമേജ്, അല്ലെങ്കിൽ amd64-ന് മാത്രം അയയ്ക്കുന്ന പാക്കേജ് ആവശ്യപ്പെടുന്ന Raspberry Pi ഇൻസ്റ്റാളേഷൻ എന്നിവയ്ക്ക് പിശക് സന്ദേശത്തിന് പകരം ശൂന്യമായ സ്ഥാനാർത്ഥി ലഭിക്കുന്നു. dpkg --print-architecture, dpkg --print-foreign-architectures എന്നിവ നിങ്ങൾ യഥാർത്ഥത്തിൽ ഏത് സെറ്റിലാണെന്ന് പറയുന്നു.

ഘടകങ്ങളും പ്രധാനമാണ്. main മാത്രം പ്രവർത്തനക്ഷമമാകുമ്പോൾ contrib അല്ലെങ്കിൽ non-free-ലെ പാക്കേജ് അദൃശ്യമാണ്, Ubuntu-യുടെ universe സമാനമായി പെരുമാറുന്നു. ഇൻഡക്സ് നിലവിലുണ്ട്, പാക്കേജ് അതിലുണ്ട്; നിങ്ങളുടെ പ്രവർത്തനക്ഷമമായ ഘടകങ്ങളുടെ പട്ടിക അത് ഉൾക്കൊള്ളുന്നില്ല എന്ന് മാത്രം.

പിൻ ചെയ്യൽ ശാന്തമായ കാരണമാണ്. /etc/apt/preferences.d-യിലെ ഒരു ഫയലിന് പാക്കേജിനെ ഇൻസ്റ്റാളേഷൻ പരിധിക്ക് താഴെ പരിമിതപ്പെടുത്താം, അപ്പോൾ തികച്ചും നല്ല സ്ഥാനാർത്ഥി ഔട്ട്പുട്ടിൽ നിന്ന് അപ്രത്യക്ഷമാകും, എന്നാൽ ഇൻഡക്സ് അത് ഇപ്പോഴും ലിസ്റ്റ് ചെയ്യുന്നു. policy ഓരോ ഉറവിടത്തിനും അടുത്ത് മുൻഗണനകൾ പ്രിന്റ് ചെയ്യുന്നതിനാൽ, ഓരോ ഉറവിടത്തിനും കുറഞ്ഞ പിൻ നമ്പർ ഉള്ള പാക്കേജാണ് സൂചന.

പഴയ ഇൻഡക്സുകൾ കാണാതായ പാക്കേജുകൾ പോലെ തോന്നുന്നു

കാഷെ ഒരു സ്നാപ്ഷോട്ടാണ്. അവസാന apt update ഒരു ഇൻഡക്സിൽ പരാജയപ്പെട്ടെങ്കിൽ, ചോദ്യങ്ങൾ പഴയ പകർപ്പിൽ നിന്ന് തന്നെ ഉത്തരം നൽകുന്നു, നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന പാക്കേജ് ആ പകർപ്പിൽ ഇല്ലായിരിക്കാം.

apt update ഓരോ ഇൻഡക്സിനും പിശകുകൾ പ്രിന്റ് ചെയ്യുന്നു, അതിനാൽ നേരെ അവസാന വരിയിലേക്ക് സ്ക്രോൾ ചെയ്യുന്നതിന് പകരം അവ വായിക്കുക.

ഒപ്പ് പിശക്, കാലഹരണപ്പെട്ട release ഫയൽ, അല്ലെങ്കിൽ എത്തിച്ചേരാനാകാത്ത കണ്ണാടി കാരണം പരാജയപ്പെടുന്ന പുതുക്കൽ മുമ്പത്തെ ഇൻഡക്സ് അതിന്റെ സ്ഥാനത്ത് വിടുന്നു. ഇത് വിവേകപൂർണ്ണമായ രൂപകൽപ്പനയാണ്, കാരണം കണ്ണാടി കുറച്ചുനേരം നിലച്ചാൽ പ്രവർത്തിക്കുന്ന കാഷെ സൂക്ഷിക്കുന്നു. പാർശ്വഫലം, റിപ്പോസിറ്ററി ഓഫ്ലൈൻ ആയിരിക്കുമ്പോഴും തിരയൽ വിജയിച്ചേക്കാം. ഇൻഡക്സ് അവസാനമായി എപ്പോൾ ലഭിച്ചു എന്ന് അറിയുന്നത് വരെ പാക്കേജിന്റെ അഭാവം ഒന്നും തെളിയിക്കുന്നില്ല എന്നും ഇത് അർത്ഥമാക്കുന്നു. പാക്കേജ് നാമത്തെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് /var/lib/apt/lists-ന് കീഴിലുള്ള ഫയൽ തീയതികൾ പരിശോധിക്കുക.

യഥാർത്ഥത്തിൽ വേണ്ട പാക്കേജിന് പേരിടുക

OpenVPN ഒരു ഡീമണാണ്, ആളുകൾ സാധാരണയായി ആഗ്രഹിക്കുന്ന ഭാഗങ്ങൾ വെവ്വേറെ പാക്കേജുകളാണ്.

എൻജിൻ, NetworkManager പ്ലഗിൻ, ഡെസ്ക്ടോപ്പ് എഡിറ്റർ എന്നിവ മൂന്ന് പേരുള്ള മൂന്ന് പാക്കേജുകളാണ്, പ്ലഗിന് ഡിസ്ട്രിബ്യൂഷനുകൾക്കിടയിൽ പേര് വ്യത്യാസപ്പെടുന്ന GTK രൂപഭേദവുമുണ്ട്. apt-cache search --names-only openvpn വിവരണങ്ങൾക്ക് പകരം പേരുകളും നൽകിയ പേരുകളും പൊരുത്തപ്പെടുത്തുന്നു, ആ വസ്തുവിന്റെ പേര് ഏകദേശം അറിയുമ്പോൾ നിങ്ങൾക്ക് വേണ്ടത് അതാണ്.

പേര് യഥാർത്ഥത്തിൽ അജ്ഞാതമാണെങ്കിൽ, ഒരിക്കൽ വിവരണങ്ങളിൽ തിരയുക, പിന്നീട് കൃത്യമായ പേരുകളിലേക്ക് മടങ്ങുക. മറ്റൊരു ഡിസ്ട്രിബ്യൂഷനിൽ നിന്ന് കടമെടുത്ത -gui പ്രത്യയം ചേർത്ത് പാക്കേജ് ഇനി നിലവിലില്ലെന്ന് തീരുമാനിക്കരുത്.

ഉറവിടങ്ങൾ അവസാനം മാറ്റുക, തുടർന്ന് ഇടപാട് പരിശോധിക്കുക

റിപ്പോസിറ്ററി ചേർക്കുന്നത് നിങ്ങളുടെ അപ്ഡേറ്റുകൾ ആരാണ് നൽകുന്നത് എന്ന് മാറ്റുന്നു, അതിനാൽ അത് അന്വേഷണത്തിന്റെ തുടക്കത്തല്ല, അവസാനത്തിൽ വരുന്നു.

അതിന് മുമ്പ് റിലീസ്, ആർക്കിടെക്ചർ, ഘടകം, പിൻ അവസ്ഥ എന്നിവ സ്ഥിരീകരിക്കുക. നാലിൽ ഏതാണ് പരിശോധിച്ചതെന്ന് എഴുതിവയ്ക്കുക, അടുത്ത വ്യക്തി വീണ്ടും മുഴുവൻ പരിശോധന നടത്താതിരിക്കാൻ. നാലും ശരിയാണെങ്കിലും സ്ഥാനാർത്ഥി ഇപ്പോഴും ഇല്ലെങ്കിൽ, സത്യസന്ധമായ നിഗമനം ഈ റിലീസ് ആ പാക്കേജ് അയയ്ക്കുന്നില്ല എന്നാണ്. ബാക്കിയുള്ള ഓപ്ഷനുകൾ backport, വെണ്ടർ പാക്കേജ്, അല്ലെങ്കിൽ മറ്റൊരു പിന്തുണയുള്ള റിലീസ് എന്നിവയാണ്, ഓരോന്നും ഊഹമല്ല, ബോധപൂർവമായ തിരഞ്ഞെടുപ്പാണ്.

സ്ഥാനാർത്ഥി പ്രത്യക്ഷപ്പെടുമ്പോൾ, പ്രയോഗിക്കുന്നതിന് മുമ്പ് അനുകരിക്കുക: പാക്കേജ് നാമത്തോടുകൂടിയ apt-get install --simulate എന്ത് വലിച്ചെടുക്കും, എന്ത് നീക്കും എന്ന് കാണിക്കുന്നു. പാക്കേജിന്റെ ലഭ്യത, ഇൻസ്റ്റാളേഷൻ, പ്രവർത്തിക്കുന്ന ടണൽ എന്നിവ മൂന്ന് വേറിട്ട ഘട്ടങ്ങളായി തുടരുന്നു, ടണലിന് ട്രാഫിക് വഹിക്കുന്നതിന് മുമ്പ് അതിന്റെ പ്രൊഫൈൽ, ക്രെഡൻഷ്യലുകൾ, റൂട്ടുകൾ, DNS എന്നിവ ഇപ്പോഴും ആവശ്യമാണ്.