Is jou VPN-binêre vir hierdie verwerker gebou? Lees die ELF-kop

Beide lêers is 32-bis en net een van hulle loop op jou bord. 'n ELF32-bou vir Intel en 'n ELF32-bou vir ARM stem oor die klasveld ooreen en verskil oor alles wat saak maak. 'n Aflaaibladsy wat 'n 32-bis-opsie bied, het jou amper niks gesê voordat jy die kop van die lêer lees wat jy werklik afgelaai het nie. Om dit te hernoem verander nie 'n enkele instruksie nie.

Klas en masjien antwoord verskillende vrae

Die klasveld sê of die lêer 32-bis- of 64-bis-strukture gebruik. Die masjienveld noem die instruksiestel waarvoor die lêer saamgestel is. Om net die eerste te lees, is hoe 'n x86-bou op 'n ARM-bord beland met 'n lêernaam wat heeltemal geloofwaardig lyk. Albei waardes kom uit dieselfde opdrag, en daarom is dit so maklik om een oor te slaan.

Dieselfde verwarring geld vir 64-bis-etikette, waar aarch64 en x86-64 'n woordgrootte deel en glad geen instruksies nie. 'n Verkoopsbladsy wat een 64-bis-aflaai lys, beskryf sy eie bou, nie jou masjien nie. Kyk na die kop van die lêer eerder as na die kolomopskrif op die bladsy.

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

Die eerste opdrag druk die kop, insluitend klas en masjien. Die tweede wys programkoppe, waar 'n interpreteerderaanvraag woon. Die derde gee jou een reël wanneer 'n tabel meer is as wat jy nodig het.

Om uitvoertoestemming by te voeg of 'n verspreidingskontrole te verander, vertaal niks nie. Emulasie, waar die platform dit ondersteun, is 'n ontplooiingsbesluit met sy eie prestasie- en afhanklikheidskoste.

Lees die kop voordat jy die installeerder laat loop

Ondersoek 'n vertroude artefak voordat jy enigiets daaruit uitvoer. 'n Installeerder wat halfpad misluk, kan biblioteke vervang laat en niks laat werk nie, wat 'n slegter beginpunt is as die argief waarmee jy begin het. Kopondersoek is leesalleen en omkeerbaar in die sin dat niks op die stelsel verander nie.

Vergelyk die masjienveld met die pakketargitektuur van die lopende stelsel, nie met die bemarkingsnaam van die bord nie. 'n 64-bis verwerker wat 'n 32-bis-gebruikersland laat loop, het die 32-bis-bou nodig, en daardie besonderheid bepaal watter aflaai inheems is. Die bord se vermoë is nie die beperking nie; die geïnstalleerde gebruikersland is.

dpkg --print-architecture
uname -m
getconf LONG_BIT

Die eerste opdrag rapporteer die argitektuur waarvoor die stelsel pakkette installeer, en dit is die waarde wat moet ooreenstem. Die ander twee beskryf die kern en die woordgrootte, en hulle kan van die gebruikersland verskil op 'n multiarch-installasie.

Wanneer daardie antwoorde verskil, besluit watter een die verskaffer ondersteun voordat jy nog 'n argief aflaai. Om te raai, skep 'n kring van installasies wat elkeen op 'n ander punt misluk, en elke mislukking lyk soos 'n nuwe probleem.

Kontroleer die interpreteerder, nie net die argitektuur nie

'n Dinamiese uitvoerbare lêer teken die laaier wat hy verwag in 'n programkop aan. Op 'n stelsel met 'n ander laaierpad weier die kern om die lêer te begin, selfs al stem die masjienveld presies ooreen. Dit is die mislukking wat mense na ontbrekende biblioteke laat soek.

Die foutboodskap sê in watter geval jy is, en die twee gevalle is maklik om te verwar. 'n Formaat- of argitektuurverwerping verskil van 'n ontbrekende lêer of interpreteerder, en net een van hulle word reggemaak deur nog 'n pakket te installeer.

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

Die eerste opdrag wys die interpreteerderpad wat die binêre lêer aanvra. Die tweede kontroleer of daardie pad bestaan, wat 'n verkeerde bou van 'n ontbrekende laaier onderskei.

Moenie 'n afhanklikheidslys op 'n onvertroude binêre lêer laat loop nie, want sommige implementasies kan die lêer uitvoer wat hulle ondersoek. Hou die ondersoek leesalleen en weerstaan die drang om laaier-skakels by te voeg om 'n onondersteunde bou te laat begin.

Vra vir 'n bou met die feite in die hand

Stuur vir die verskaffer die bedryfstelselweergawe, die pakketargitektuur, die klas- en masjienwaardes en die eerste foutboodskap. Daardie kombinasie verdien 'n nuttige antwoord, terwyl 'n skermskoot van 'n algemene fout 'n ondersteuningsjabloon verdien.

Hou die binêre vraag apart van die konfigurasievraag. Sodra die korrekte bou begin, is profiele, aanmeldgegewens en roetes steeds hul eie probleme, en geen hoeveelheid profielredigering sal 'n binêre lêer met die verkeerde argitektuur laat loop nie.