pppd ബൈനറി കണ്ടെത്തിയില്ല: റൺടൈം ശരിയാക്കുക, പ്രമാണീകരണമല്ല
pppd ഇല്ലാതിരിക്കുന്നത് പ്രാദേശിക റൺടൈം മുൻവ്യവസ്ഥയാണ്, നിരസിച്ച പാസ്വേഡല്ല. എന്തെങ്കിലും നീക്കം ചെയ്യുന്നതിന് മുമ്പ് പാക്കേജും വിളിക്കുന്നയാളുടെ പാതയും പരിശോധിക്കുക.
ഗേറ്റ്വേയിലേക്ക് ഒന്നും എത്തിയില്ല, കാരണം ക്ലയന്റിന് ആദ്യം ആവശ്യമുള്ള ബൈനറി കണ്ടെത്താനായില്ല. സന്ദേശം റൺടൈം സഹായിയെ പേരിടുന്നു, സ്വാഭാവിക പ്രതികരണം മറുവശം എന്തോ നിരസിച്ചു എന്ന് അനുമാനിക്കുകയാണ്. അത് നിരസിച്ചില്ല. PPP അടിസ്ഥാനമാക്കിയ സംയോജനത്തിന് ആ സഹായി പ്രാദേശിക മെഷീനിൽ ആവശ്യമാണ്, അത് ഇല്ല, വായിക്കാനാകുന്നില്ല അല്ലെങ്കിൽ വിളിക്കുന്നയാൾ നോക്കുന്നിടത്ത് ഇല്ല.
മെനുവും ഡീമണും വ്യത്യസ്ത കാര്യങ്ങളാണ്
ഡെസ്ക്ടോപ്പ് എഡിറ്റർ ഒരു പ്രൊഫൈൽ സേവ് ചെയ്യാം, അത് സ്ഥാപിക്കേണ്ട സഹായി ഇല്ലെങ്കിലും, കാരണം സേവ് ചെയ്യൽ ഫീൽഡുകൾ പരിശോധിക്കുന്നു, കഴിവുകളല്ല. രണ്ട് ഘടകങ്ങളും വ്യത്യസ്ത പാക്കേജുകളിൽ വരുന്നു, വ്യത്യസ്ത നിമിഷങ്ങളിൽ പരാജയപ്പെടുന്നു. വൃത്തിയായി സേവ് ചെയ്യുന്ന പ്രൊഫൈലും ഉടനടി പരാജയപ്പെടുന്ന കണക്ഷനും പൂർണ്ണമായി സുസ്ഥിരമാണ്.
വിപരീത തെറ്റും അത്ര സാധാരണമാണ്: ഡിസ്കിൽ എവിടെയോ ഉള്ള എക്സിക്യൂട്ടബിൾ തിരഞ്ഞെടുത്ത സംയോജനം പിന്തുണയ്ക്കുന്ന പകർപ്പ് കണ്ടെത്തുന്നു എന്ന് തെളിയിക്കുന്നില്ല. ഹോം ഡയറക്ടറിയിലെ പകർപ്പ് ഒരു ഷെല്ലിനെ തൃപ്തിപ്പെടുത്തിയേക്കാം, എന്നിട്ടും സേവനത്തിന് അദൃശ്യമായി തുടരാം.
ഫയലല്ല, പാക്കേജ് വായിക്കുക
എന്തെങ്കിലും തൊടുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത പാക്കേജിന്റെ അവസ്ഥ, പ്രഖ്യാപിത ആശ്രിതത്വങ്ങൾ, പ്രതീക്ഷിത ഫയൽ പട്ടിക എന്നിവ പരിശോധിക്കുക. ഡിസ്ട്രിബ്യൂഷനുകളുടെ പാക്കേജിംഗ് ഇത് വ്യക്തമായി രേഖപ്പെടുത്തുന്നു, Debian ന്റെ NetworkManager PPTP പാക്കേജ് ഉപയോഗപ്രദമായ ഉദാഹരണമാണ്, കാരണം അത് PPP ഡീമൺ പാക്കേജിനെയും PPTP ക്ലയന്റിനെയും വെവ്വേറെ ആശ്രയിക്കുന്നു. ഇത് ഇന്ന് PPTP വിന്യസിക്കാനുള്ള ശുപാർശയല്ല, പഴയ സംയോജനമാണ്. സഹായി ക്ലയന്റിനുള്ളിലല്ല, സ്വന്തം ആശ്രിതത്വമായി എത്തുന്നത് ഇത് കാണിക്കുന്നു.
പരാജയത്തിന്റെ മൂന്ന് രീതികൾ വേർതിരിക്കുക: ഇൻസ്റ്റാൾ ചെയ്യാത്ത പാക്കേജ്, സ്ഥാനാർത്ഥി നൽകാത്ത റിപ്പോസിറ്ററി, പാക്കേജിന്റെ ഉടമസ്ഥതയ്ക്ക് പുറത്ത് കൈകൊണ്ട് ഇൻസ്റ്റാൾ ചെയ്ത ബൈനറി. ഇവയ്ക്ക് വ്യത്യസ്ത അറ്റകുറ്റപ്പണികൾ വേണം, ഒന്നാമത്തേത് മാത്രമേ അതേ പാക്കേജ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്ത് ശരിയാക്കൂ.
ഒരു ഷെല്ലിലെ എക്സിക്യൂട്ടബിൾ പരിശോധന ആ ഷെല്ലിന്റെ തിരയൽ പാത മാത്രം വിവരിക്കുന്നു, അതിൽ കൂടുതലൊന്നുമില്ല. മാനേജറുടെ സഹായി മറ്റൊരു പാതയിൽ, മറ്റൊരു പരിതസ്ഥിതിയിൽ അല്ലെങ്കിൽ വ്യക്തമായി ക്രമീകരിച്ച എക്സിക്യൂട്ടബിൾ സ്ഥാനത്ത് പ്രവർത്തിച്ചേക്കാം.
dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppdമറ്റുള്ളവ തകർക്കാതെ റൺടൈം ശരിയാക്കുക
റൺടൈം വ്യക്തമായി അപൂർണ്ണമാകുമ്പോൾ, ഡിസ്ട്രിബ്യൂഷന്റെ അവലോകനം ചെയ്ത പാക്കേജ് ഇടപാട് ഉപയോഗിക്കുക, എന്ത് മാറ്റുമെന്ന് ആദ്യം വായിക്കുക. PPP പല ആക്സസ് നെറ്റ്വർക്ക് സംയോജനങ്ങളും പങ്കിടുന്നു, അതിനാൽ അത് നീക്കം ചെയ്യുന്നതോ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതോ പ്രവർത്തിക്കുന്ന ഉപഭോക്താക്കളെ കൂടെ കൊണ്ടുപോകാം. ഒരു കേടായത് ശരിയാക്കാൻ ബന്ധപ്പെട്ട എല്ലാ പാക്കേജുകളും വൃത്തിയാക്കുന്നതാണ് ലാപ്ടോപ്പ് രണ്ട് പ്രവർത്തിക്കുന്ന കണക്ഷനുകൾ നഷ്ടപ്പെടുന്ന വഴി.
മറ്റൊരു VPN ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യുന്നതും അറ്റകുറ്റപ്പണിയല്ല. അത് പുതിയ അനുയോജ്യതാ ആവശ്യകത സൃഷ്ടിക്കുകയും യഥാർത്ഥ പ്രൊഫൈൽ വിശദീകരിക്കാതെ വിടുകയും ചെയ്യുന്നു.
പ്രോട്ടോക്കോൾ തന്നെ പോകണമെന്ന് സംഘടന തീരുമാനിച്ചിട്ടുണ്ടെങ്കിൽ, അത് ഉടമയുള്ള കുടിയേറ്റ തീരുമാനമാണ്. അത് പ്രശ്നപരിഹാര ഘട്ടമല്ല, കണക്ഷൻ പരാജയപ്പെടുന്ന നിമിഷത്ത് അത് എടുക്കരുത്.
അടുത്ത പിശകിനെ പുതിയ ഘട്ടമായി കാണുക
സഹായി ആരംഭിച്ചാൽ, അടുത്ത പരാജയം വ്യത്യസ്തമായിരിക്കുമെന്ന് പ്രതീക്ഷിക്കുക. PPP ലിങ്ക് ചർച്ച, ഉപയോക്തൃ പ്രമാണീകരണം, വിലാസ വിതരണം, റൂട്ടുകൾ, പേര് നിർണ്ണയം എന്നിവ ഓരോന്നും സ്വതന്ത്രമായി പരാജയപ്പെടാം, ഓരോന്നിനും സ്വന്തം തെളിവുണ്ട്.
പിന്നീടുള്ള നിരസനത്തോട് ആശ്രിതത്വ അറ്റകുറ്റപ്പണി പിൻവലിച്ചോ പ്രൊഫൈലിലെ എല്ലാ പഴയ പ്രമാണീകരണ, കംപ്രഷൻ ഓപ്ഷനുകളും ഓണാക്കിയോ പ്രതികരിക്കരുത്. അത് ഒരു രോഗനിർണ്ണയം ചെയ്യാവുന്ന പ്രശ്നത്തെ പരസ്പരം സ്വാധീനിക്കുന്ന പലതാക്കി മാറ്റുന്നു. ഒരു സമയത്ത് ഒരു ക്രമീകരണം മാറ്റി, അത് എന്ത് മാറ്റി എന്ന് രേഖപ്പെടുത്തുക.
പാക്കേജ് പതിപ്പുകളും നിങ്ങൾ കണ്ട കൃത്യമായ സന്ദേശവും രേഖപ്പെടുത്തുക. കാണാത്ത ബൈനറിയും അത് നൽകേണ്ട പാക്കേജും പേരിടുന്ന റിപ്പോർട്ട്, VPN നെക്കുറിച്ചുള്ള പൊതുവായ പരാതിക്കില്ലാത്ത രീതിയിൽ പ്രവർത്തനക്ഷമമാണ്.