നിങ്ങളുടെ VPN ബൈനറി ഈ CPU-യ്ക്കായി നിർമ്മിച്ചതാണോ? ELF ഹെഡർ വായിക്കുക

രണ്ട് ഫയലുകളും 32-ബിറ്റാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് നിങ്ങളുടെ ബോർഡിൽ പ്രവർത്തിക്കുന്നത്. Intel-നുള്ള ELF32 ബിൽഡും ARM-നുള്ള ELF32 ബിൽഡും ക്ലാസ് ഫീൽഡിൽ യോജിക്കുന്നു, പ്രധാനമായ എല്ലാ കാര്യങ്ങളിലും വിയോജിക്കുന്നു. 32-ബിറ്റ് ഓപ്ഷൻ നൽകുന്ന ഡൗൺലോഡ് പേജ്, നിങ്ങൾ യഥാർത്ഥത്തിൽ ഡൗൺലോഡ് ചെയ്ത ഫയലിന്റെ ഹെഡർ വായിക്കുന്നതുവരെ നിങ്ങളോട് ഏതാണ്ട് ഒന്നും പറഞ്ഞിട്ടില്ല. പേര് മാറ്റുന്നത് ഒരു നിർദ്ദേശവും മാറ്റുന്നില്ല.

ക്ലാസും മെഷീനും വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു

ഫയൽ 32-ബിറ്റ് അല്ലെങ്കിൽ 64-ബിറ്റ് ഘടനകൾ ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് ക്ലാസ് ഫീൽഡ് പറയുന്നു. ഫയൽ കംപൈൽ ചെയ്ത നിർദ്ദേശ കൂട്ടത്തിന്റെ പേര് മെഷീൻ ഫീൽഡ് നൽകുന്നു. ആദ്യത്തേത് മാത്രം വായിക്കുന്നതാണ്, പൂർണ്ണമായി വിശ്വസനീയമായി തോന്നുന്ന ഫയൽ നാമത്തോടെ x86 ബിൽഡ് ARM ബോർഡിൽ എത്തുന്ന വഴി. രണ്ട് മൂല്യങ്ങളും ഒരേ കമാന്റിൽ നിന്നാണ് വരുന്നത്, അതിനാൽ ഒന്ന് ഒഴിവാക്കുന്നത് വളരെ എളുപ്പമാണ്.

അതേ ആശയക്കുഴപ്പം 64-ബിറ്റ് ലേബലുകൾക്കും ബാധകമാണ്, അവിടെ aarch64-ഉം x86-64-ഉം വാക്കിന്റെ വലുപ്പം പങ്കിടുന്നു, ഒരു നിർദ്ദേശവും പങ്കിടുന്നില്ല. ഒരു 64-ബിറ്റ് ഡൗൺലോഡ് മാത്രം ലിസ്റ്റ് ചെയ്യുന്ന വിൽപ്പനക്കാരന്റെ പേജ് അവരുടെ സ്വന്തം ബിൽഡ് വിവരിക്കുന്നു, നിങ്ങളുടെ മെഷീനല്ല. പേജിലെ കോളം തലക്കെട്ടിന് പകരം ഫയലിന്റെ ഹെഡർ പരിശോധിക്കുക.

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

ആദ്യ കമാന്റ് ഹെഡർ പ്രിന്റ് ചെയ്യുന്നു, ക്ലാസും മെഷീനും ഉൾപ്പെടെ. രണ്ടാമത്തേത് പ്രോഗ്രാം ഹെഡറുകൾ കാണിക്കുന്നു, ഇന്റർപ്രിറ്റർ അഭ്യർത്ഥന അവിടെയാണ്. മൂന്നാമത്തേത് പട്ടിക നിങ്ങൾക്ക് ആവശ്യമുള്ളതിലധികമാകുമ്പോൾ ഒരു വരി തരുന്നു.

എക്സിക്യൂട്ട് അനുമതി ചേർക്കുന്നതോ ഡിസ്ട്രിബ്യൂഷൻ പരിശോധന പാച്ച് ചെയ്യുന്നതോ ഒന്നും വിവർത്തനം ചെയ്യുന്നില്ല. പ്ലാറ്റ്ഫോം പിന്തുണയ്ക്കുന്നിടത്ത് എമുലേഷൻ, സ്വന്തം പ്രകടന-ആശ്രിതത്വ ചെലവുള്ള വിന്യാസ തീരുമാനമാണ്.

ഇൻസ്റ്റാളർ പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് ഹെഡർ വായിക്കുക

വിശ്വസനീയമായ ഒരു ആർട്ടിഫാക്ടിൽ നിന്ന് എന്തെങ്കിലും പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് അത് പരിശോധിക്കുക. പകുതി വഴിയിൽ പരാജയപ്പെടുന്ന ഇൻസ്റ്റാളർ ലൈബ്രറികൾ മാറ്റപ്പെട്ടതും ഒന്നും പ്രവർത്തിക്കാത്തതുമായ അവസ്ഥ ബാക്കിയാക്കാം, ഇത് നിങ്ങൾ തുടങ്ങിയ ആർക്കൈവിനെക്കാൾ മോശം ആരംഭബിന്ദുവാണ്. ഹെഡർ പരിശോധന വായനയ്ക്ക് മാത്രമുള്ളതാണ്, സിസ്റ്റത്തിൽ ഒന്നും മാറുന്നില്ല എന്ന അർത്ഥത്തിൽ പഴയപടിയാക്കാനാകും.

മെഷീൻ ഫീൽഡിനെ പ്രവർത്തിക്കുന്ന സിസ്റ്റത്തിന്റെ പാക്കേജ് ആർക്കിടെക്ചറുമായി താരതമ്യം ചെയ്യുക, ബോർഡിന്റെ മാർക്കറ്റിംഗ് പേരുമായല്ല. 32-ബിറ്റ് ഉപയോക്തൃ സ്ഥലം പ്രവർത്തിപ്പിക്കുന്ന 64-ബിറ്റ് CPU-യ്ക്ക് 32-ബിറ്റ് ബിൽഡ് ആവശ്യമാണ്, ആ വിശദാംശമാണ് ഏത് ഡൗൺലോഡ് സ്വദേശീയമെന്ന് തീരുമാനിക്കുന്നത്. ബോർഡിന്റെ കഴിവല്ല പരിമിതി; ഇൻസ്റ്റാൾ ചെയ്ത ഉപയോക്തൃ സ്ഥലമാണ്.

dpkg --print-architecture
uname -m
getconf LONG_BIT

സിസ്റ്റം ഏത് ആർക്കിടെക്ചറിനായി പാക്കേജുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു എന്ന് ആദ്യ കമാന്റ് റിപ്പോർട്ട് ചെയ്യുന്നു, ആ മൂല്യമാണ് യോജിക്കേണ്ടത്. ബാക്കി രണ്ടും കേർണലും വാക്കിന്റെ വലുപ്പവും വിവരിക്കുന്നു, ഒന്നിലധികം ആർക്കിടെക്ചർ ഇൻസ്റ്റാളിൽ അവ ഉപയോക്തൃ സ്ഥലവുമായി വിയോജിച്ചേക്കാം.

ആ ഉത്തരങ്ങൾ വിയോജിക്കുമ്പോൾ, മറ്റൊരു ആർക്കൈവ് ഡൗൺലോഡ് ചെയ്യുന്നതിന് മുമ്പ് വിൽപ്പനക്കാരൻ ഏതിനെ പിന്തുണയ്ക്കുന്നു എന്ന് തീരുമാനിക്കുക. ഊഹം ഓരോന്നും വ്യത്യസ്ത ഘട്ടത്തിൽ പരാജയപ്പെടുന്ന ഇൻസ്റ്റാളുകളുടെ ഒരു കണ്ണി സൃഷ്ടിക്കുന്നു, ഓരോ പരാജയവും പുതിയ പ്രശ്നമായി തോന്നുന്നു.

ഇന്റർപ്രിറ്റർ പരിശോധിക്കുക, ആർക്കിടെക്ചർ മാത്രമല്ല

ഡൈനാമിക് എക്സിക്യൂട്ടബിൾ പ്രോഗ്രാം ഹെഡറിൽ താൻ പ്രതീക്ഷിക്കുന്ന ലോഡർ രേഖപ്പെടുത്തുന്നു. വ്യത്യസ്ത ലോഡർ പാതയുള്ള സിസ്റ്റത്തിൽ മെഷീൻ ഫീൽഡ് കൃത്യമായി യോജിച്ചാലും കേർണൽ ഫയൽ പ്രവർത്തിപ്പിക്കാൻ വിസമ്മതിക്കുന്നു. ഇതാണ് ആളുകളെ കാണാത്ത ലൈബ്രറികൾ തിരയാൻ അയയ്ക്കുന്ന പരാജയം.

പിശക് സന്ദേശം നിങ്ങൾ ഏത് സാഹചര്യത്തിലാണെന്ന് പറയുന്നു, രണ്ട് സാഹചര്യങ്ങളും ആശയക്കുഴപ്പത്തിലാക്കാൻ എളുപ്പമാണ്. ഫോർമാറ്റോ ആർക്കിടെക്ചറോ നിരസിക്കുന്നത് കാണാത്ത ഫയലിൽ നിന്നോ ഇന്റർപ്രിറ്ററിൽ നിന്നോ വ്യത്യസ്തമാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് മറ്റൊരു പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്ത് ശരിയാകുന്നത്.

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

ബൈനറി ആവശ്യപ്പെടുന്ന ഇന്റർപ്രിറ്റർ പാത ആദ്യ കമാന്റ് കാണിക്കുന്നു. രണ്ടാമത്തേത് ആ പാത നിലവിലുണ്ടോ എന്ന് പരിശോധിക്കുന്നു, ഇത് തെറ്റായ ബിൽഡിനെ കാണാത്ത ലോഡറിൽ നിന്ന് വേർതിരിക്കുന്നു.

വിശ്വസനീയമല്ലാത്ത ബൈനറിയിൽ ആശ്രിതത്വ പട്ടിക പ്രവർത്തിപ്പിക്കരുത്, കാരണം ചില നിർവ്വഹണങ്ങൾ അവ പരിശോധിക്കുന്ന ഫയൽ പ്രവർത്തിപ്പിച്ചേക്കാം. പരിശോധന വായനയിൽ മാത്രം നിർത്തുക, പിന്തുണയില്ലാത്ത ബിൽഡ് പ്രവർത്തിപ്പിക്കാൻ ലോഡർ സിംബോളിക് ലിങ്കുകൾ ചേർക്കാനുള്ള പ്രലോഭനത്തെ എതിർക്കുക.

വസ്തുതകൾ കൈയിലുള്ളപ്പോൾ ഒരു ബിൽഡ് ചോദിക്കുക

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

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