നിങ്ങളുടെ Raspberry Pi-ക്ക് പഴയ openfortivpn .deb അനുയോജ്യമാണോ?

ഒരു ഫോറം ഉത്തരം നിങ്ങൾക്ക് പൂർണ്ണ ഫയൽനാമം നൽകുന്നു, ഫയൽനാമം പരിഹാരം പോലെ തോന്നുന്നു: ഒരു .deb, ഒരു കമാൻഡ്, കഴിഞ്ഞു. ആ സ്ട്രിംഗ് യഥാർത്ഥത്തിൽ എൻകോഡ് ചെയ്യുന്നത് പാക്കേജ് പതിപ്പ്, CPU ആർക്കിടെക്ചർ, ആരോ പോസ്റ്റ് എഴുതിയ ദിവസം അത് എതിർത്ത് നിർമ്മിച്ച ഡിസ്ട്രിബ്യൂഷൻ സ്യൂട്ട് എന്നിവയാണ്. ആ മൂന്നിൽ ഒന്നും നിങ്ങളുടെ മേശയിലെ ബോർഡിനെ സ്വയമേവ വിവരിക്കുന്നില്ല. പഴയ ഡൗൺലോഡ് ഒരു മെഷീന്റെ അവസ്ഥയുടെ സ്നാപ്ഷോട്ടാണ്, നിങ്ങൾക്കുള്ള ഇൻസ്റ്റലേഷൻ പ്ലാനല്ല.

ഫയൽനാമം നിശബ്ദമായി എന്താണ് പിൻ ചെയ്യുന്നത്

openfortivpn_1.17.0-1_armhf.deb പോലുള്ള ഒരു പേര് വലത്തുനിന്ന് ഇടത്തോട്ട് വായിക്കുക. പ്രത്യയം ബൈനറി കംപൈൽ ചെയ്ത ആർക്കിടെക്ചറാണ്, മധ്യ ഫീൽഡ് upstream ഉം പാക്കേജിംഗ് റിവിഷനും ആണ്, സൂചിതമായ നാലാമത്തെ ഫീൽഡ് അത് നിർമ്മിച്ച സ്യൂട്ടിന്റെ ലൈബ്രറി ഗണമാണ്.

64-ബിറ്റ് Raspberry Pi OS ഇൻസ്റ്റലേഷനിൽ സിസ്റ്റം ആർക്കിടെക്ചർ arm64 ആണ്, അതിനാൽ dpkg -i ആർക്കിടെക്ചർ പൊരുത്തക്കേട് കാരണം armhf പാക്കേജ് നിരസിക്കുന്നു. multiarch ഇൻസ്റ്റാൾ സാധ്യമാക്കുന്നിടത്തും, ബൈനറി താൻ നിർമ്മിച്ച റിലീസിലെ ലൈബ്രറി പതിപ്പുകൾ പ്രതീക്ഷിക്കുന്നു, പുതിയ ബേസ് സിസ്റ്റം അവ ഇനി നൽകിയെന്നു വരില്ല. ഫലം അതിന്റെ എക്സിക്യൂട്ടബിൾ പ്രവർത്തനക്ഷമമല്ലാത്ത ഇൻസ്റ്റാൾ ചെയ്ത പാക്കേജാണ്, ഇതാണ് ആളുകൾ സാധാരണയായി ക്ലയന്റ് തന്നെ കേടായതാണെന്ന് തെറ്റായി മനസ്സിലാക്കുന്ന പരാജയം.

ബോർഡ് ARM ഉപകരണമായത് ARM പാക്കേജിനെ അനുയോജ്യമാക്കുന്നില്ല. ആർക്കിടെക്ചർ ഒരു അക്ഷമാണ്; റിലീസും ABI-യും മറ്റ് രണ്ടും, അവ സ്വതന്ത്രമായി പരാജയപ്പെടുന്നു.

ഡൗൺലോഡ് ലിങ്ക് ചോദിക്കുന്നതിന് മുമ്പ് ഡിസ്ട്രിബ്യൂഷനോട് ചോദിക്കുക

പരിപാലിക്കുന്ന ഓരോ ചാനലും ഇപ്പോൾ എന്ത് ഇൻസ്റ്റാൾ ചെയ്യുമെന്ന് പറയാൻ കഴിയും. ഏതെങ്കിലും ഫയൽ കൈമാറ്റം പരിഗണിക്കുന്നതിന് മുമ്പ് ലക്ഷ്യ മെഷീനിൽ, അത് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന റിപ്പോസിറ്ററികളോടൊപ്പം ക്വറി പ്രവർത്തിപ്പിക്കുക.

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

പതിപ്പും റിപ്പോസിറ്ററി പേരും ഉള്ള കാൻഡിഡേറ്റ് ലൈൻ എന്നാൽ ഡിസ്ട്രിബ്യൂഷന് ഈ സിസ്റ്റത്തിനുള്ള ബിൽഡ് ഇതിനകം ഉണ്ട്. കാൻഡിഡേറ്റ് ഇല്ലാതിരിക്കുകയോ, ഉപയോഗിക്കാൻ ഉദ്ദേശിക്കാത്ത സ്യൂട്ടിൽ നിന്ന് കാൻഡിഡേറ്റ് വരികയോ ചെയ്യുന്നത് സോഫ്റ്റ്വെയർ എവിടെയോ ഉണ്ടോ എന്നതിനെക്കുറിച്ചല്ല, നിങ്ങളുടെ സ്രോതസ്സുകളെക്കുറിച്ചുള്ള വിവരമാണ്.

മെറ്റാഡാറ്റ പുതുക്കൽ പരാജയപ്പെട്ടാൽ, ആ പരാജയം പാക്കേജ് ചോദ്യത്തിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുക. പേര് റിസോൾവിംഗ്, റിപ്പോസിറ്ററി ഗതാഗതം, കാണാത്ത Release ഒപ്പ്, ആയുസ്സവസാനിച്ച സ്യൂട്ട്—എല്ലാം ക്ലയന്റ് ഇടപെടുന്നതിന് മുമ്പേ apt update തകർക്കുന്നു. സ്രോതസ്സുകൾ ശരിയാക്കുന്നത് VPN ക്ലയന്റ് തിരഞ്ഞെടുക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ജോലിയാണ്, രണ്ടും കലർത്തുന്നതാണ് ആളുകൾ നിലവിലെ സിസ്റ്റത്തെ കാലഹരണപ്പെട്ട റിലീസിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്ന വഴി.

apt എന്താണ് സ്ഥിരീകരിക്കുന്നത്, ഡൗൺലോഡ് ചെയ്ത ഫയലിന് എന്ത് ലഭിക്കുന്നില്ല

സാധാരണ ഇൻസ്റ്റലേഷൻ ഒപ്പുകളുടെ ഒരു ശൃംഖല പിന്തുടരുന്നു: ആർക്കൈവ് അതിന്റെ സൂചികയിൽ ഒപ്പിടുന്നു, സൂചിക ഓരോ പാക്കേജിന്റെയും ഹാഷുകൾ വഹിക്കുന്നു, പാക്കേജ് പൊരുത്തപ്പെടണം. ആർക്കൈവ് ഓതന്റിക്കേഷൻ റഫറൻസ് ആ ശൃംഖലയെ ഓരോ വ്യക്തിഗത ഫയലിനോടും ഘടിപ്പിച്ച ഒപ്പ് പരിശോധിക്കുന്ന ആശയത്തിൽ നിന്ന് വേർതിരിക്കുന്നു.

പഴയ HTTP ലിങ്കിൽ നിന്ന് സംരക്ഷിച്ച ഫയലിൽ അതിൽ ഒന്നുമില്ല. അത് റിപ്പോസിറ്ററി ഐഡന്റിറ്റിയില്ലാതെ എത്തുന്നു, ഡിസ്ട്രിബ്യൂഷൻ ക്ലയന്റ് പാച്ച് ചെയ്യുമ്പോൾ അത് അപ്ഡേറ്റ് ചെയ്യുന്നില്ല, അത് മാറ്റിസ്ഥാപിക്കാൻ ആരാണ് ഉത്തരവാദി എന്ന് ഒന്നും രേഖപ്പെടുത്തുന്നില്ല. പിൻ ചെയ്ത ആർട്ടിഫാക്ടുള്ള അഡ്മിനിസ്ട്രേറ്റർക്ക് ഇത് ഇപ്പോഴും സാധുവായ തിരഞ്ഞെടുപ്പാകാം, പക്ഷേ തിരഞ്ഞെടുപ്പിനൊപ്പം ഉടമ, എവിടെയെങ്കിലും രേഖപ്പെടുത്തിയ ചെക്ക്സം, അടുത്ത സുരക്ഷാ അപ്ഡേറ്റിനുള്ള പ്ലാൻ എന്നിവ ഉണ്ടായിരിക്കണം.

പഴയ നിർദ്ദേശം പ്രവർത്തിക്കാൻ ഒപ്പ് പിശകുകൾ അടിച്ചമർത്തുന്നതോ TLS പരിശോധന നിർത്തുന്നതോ എന്തെങ്കിലും പരിശോധിച്ചിരുന്ന ഏക ഭാഗം നീക്കം ചെയ്യുന്നു. പകരം പരാജയപ്പെടുന്ന പരിശോധന പുനഃസ്ഥാപിക്കുക.

ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യുക, പിന്നീട് കണക്ഷൻ വെവ്വേറെ ഡീബഗ് ചെയ്യുക

പരിപാലിക്കുന്ന കാൻഡിഡേറ്റ് ഉണ്ടെങ്കിൽ, സാധാരണ അവലോകനം ചെയ്ത ഇടപാടിലൂടെ അത് ഇൻസ്റ്റാൾ ചെയ്യുക, പാക്കേജ് മാനേജർ എന്ത് ചെയ്തു എന്ന് രേഖപ്പെടുത്താൻ അനുവദിക്കുക.

വിന്യാസത്തിന് യഥാർത്ഥത്തിൽ upstream ബിൽഡ് ആവശ്യമെങ്കിൽ, പ്രോജക്റ്റിന്റെ നിലവിലെ ബിൽഡ് നിർദ്ദേശങ്ങൾ പാലിക്കുക, ഇപ്പോൾ നിങ്ങൾ പരിപാലിക്കുന്ന സോഫ്റ്റ്വെയറായി അതിനെ കാണുക: ഡെവലപ്മെന്റ് പാക്കേജുകൾ, pkg-config, TLS ലൈബ്രറിയുടെ ഹെഡറുകൾ, PPP ഡീമൺ എന്നിവ യഥാർത്ഥ ആശ്രിതത്വങ്ങളാണ്, പിന്നീട് നിങ്ങൾക്ക് വേണ്ടിവരുന്ന നീക്കം ചെയ്യൽ നടപടിക്രമവും അങ്ങനെതന്നെ.

ഇൻസ്റ്റലേഷൻ പ്രാദേശിക സോഫ്റ്റ്വെയർ ഘട്ടം മാത്രമാണ്. ഗേറ്റ്വേ ക്ലയന്റിന്റെ പ്രോട്ടോക്കോളും ഓതന്റിക്കേഷൻ ഫ്ലോയും സ്വീകരിക്കണം, ക്ലയന്റ് ഗേറ്റ്വേ അവതരിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റിൽ വിശ്വസിക്കണം, ടണലിന് പ്രവർത്തിക്കുന്ന PPP പാളിയും റൂട്ടുകളും റിസോൾവർ ഉടമയും വേണം. പൂർത്തിയായ പാക്കേജ് ഇടപാട് ഗേറ്റ്വേ അക്കൗണ്ട് സ്വീകരിക്കുന്നുണ്ടോ അല്ലെങ്കിൽ സ്വകാര്യ ശ്രേണി എത്താവുന്നതാണോ എന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ഇൻസ്റ്റാളർ വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നതിന് പകരം തകരുന്നിടത്ത് ഓരോ പാളിയും പരിശോധിക്കുക.

പഴയ ഫയൽനാമം മാറ്റിസ്ഥാപിക്കേണ്ട പ്ലാൻ

ആദ്യം പ്ലാറ്റ്ഫോം ഐഡന്റിറ്റി എഴുതുക: OS റിലീസ്, ആർക്കിടെക്ചർ, ഉപയോഗിക്കുന്ന സ്രോതസ്സ് പട്ടിക. തുടർന്ന് പാക്കേജ് വരുന്ന അധികാരമുള്ള സ്ഥലം പേരിടുക—അത് ഡിസ്ട്രിബ്യൂഷൻ റിപ്പോസിറ്ററിയോ, പിൻ ചെയ്ത കീയുള്ള വെണ്ടർ റിപ്പോസിറ്ററിയോ, നിങ്ങൾ തന്നെ കംപൈൽ ചെയ്ത് പാക്കേജ് ചെയ്യുന്ന ബിൽഡോ ആകാം.

അവസാനം പരിപാലകനെയും അപ്ഡേറ്റ് പാതയും പേരിടുക. ഉടമയില്ലാത്ത ക്ലയന്റ് പ്രവർത്തിപ്പിക്കുന്ന Pi ആദ്യ ലൈബ്രറി അപ്ഡേറ്റ് വരെ പ്രവർത്തിക്കും, പിന്നീട് അതേ പ്രശ്നമുള്ള ഒരാൾ അതേ ഫോറം ത്രെഡ് വീണ്ടും കണ്ടെത്തും.

തിരുത്തിയ വിശ്വാസം ഒരു വരിയിൽ പറയാൻ മാത്രം ലളിതമാണ്: പഴയ പാക്കേജ് ക്ലയന്റ് ഒരിക്കൽ നിർമ്മിക്കപ്പെട്ടു പ്രവർത്തിച്ചു എന്നതിന്റെ തെളിവാണ്, ഇന്ന് രാത്രി നിങ്ങളുടെ ബോർഡിൽ ഇൻസ്റ്റാൾ ചെയ്യുമെന്നതിന്റെ തെളിവല്ല. മൂന്ന് അക്ഷങ്ങളും പരിശോധിച്ച്, അപ്ഡേറ്റ് ചെയ്തുകൊണ്ടിരിക്കാൻ കഴിയുന്ന ഒരു ചാനൽ തിരഞ്ഞെടുക്കുക.