OpenConnect macOS-en: csomag, kiadási archívum vagy git klón

A Homebrew egy binárist és egy hálózati szkriptet ad; a forrásfa egyiket sem adja, amíg nem hozza létre és futtatja őket. Tudja, melyiket használja a kapcsolata.

Három útvonal ad OpenConnect-klienst egy Macen, és különböző dolgokat hagynak a lemezen. A Homebrew-képlet telepít egy lefordított binárist és azt a hálózati szkriptet, amely az útvonalakat és a DNS-t beállítja. A kiadási archívum forráskódot ad generált buildrendszerrel. A git-másolat forráskódot ad anélkül. A rossz választás az oka, hogy az emberek néhány perccel egy útmutató elkezdése után egy hiányzó configure-ral találkoznak.

Két különböző gép ugyanazon a néven

A csomag útvonala egyetlen parancs, és ez a helyes alapértelmezés mindenkinek, akinek a munkája a csatlakozás, nem a fejlesztés.

brew install openconnect

Amit telepít, fontosabb a parancsnál. Megkapja a kliens binárisát, és megkapja a vpnc-script-et is, amelyet a kliens az interfész, az útvonalak és a feloldó programozásához hív. A kettő párként működik: a bináris lezárja a TLS-munkamenetet, és átadja a létrejött interfészt a szkriptnek, a szkript pedig az a rész, amely tudja, hogyan akarja ez az operációs rendszer megváltoztatni a hálózatát.

Ez a szétválasztás a zavaró jelentések egész osztályát magyarázza. Az a kliens, amely csatlakozik, sikert jelent, majd a forgalmat rossz útra küldi, általában szkriptprobléma, nem alagútprobléma, és a képlet újratelepítése csak azért javítja meg, mert a szkript is újratelepül. Ellenőrizze a képlet jelenlegi macOS- és CPU-architektúra-támogatását, mielőtt számítana rá; egy Mac, amely tökéletesen futtat egy shellt, még mindig nem kaphatott aktuális, rá épített csomagot.

Mit tesz valójában a forrás útvonala

A kiadási archívum generált buildrendszerrel érkezik, így az ismert ./configure már az elejétől létezik. A git-másolatban nem, mert a generált fájlok buildtermékek, nem pedig a projekt által tárolt dolgok. Pontosan ezért jelenik meg a ./autogen.sh a másolatokhoz szóló utasításokban, és nem a kiadási archívumokéban.

./autogen.sh
./configure
make
make install

Minden sor tesz valami konkrétat, és tudni, melyik hibázott, sok találgatást takarít meg. Az autogen lépés lefuttatja az autotools-t, hogy előállítsa a configure-t. A configure lépés megvizsgálja a kliens számára szükséges fordítót, könyvtárakat és fejléceket, majd megírja a makefile-okat, amelyek tükrözik, amit talált. A make lépés lefordít. Az install lépés átmásolja az eredményeket valahová az elérési útjára.

Éppen ezen az utolsó soron szokott félremenni a tanács. A telepítés nem bizonyítéka annak, hogy a build működött, és tetszőleges letöltési mappában, emelt jogosultságokkal futtatni jó módja annak, hogy szétszórjon fájlokat, amelyekre később nem fog emlékezni. Ha a configure egy hiányzó könyvtár miatt hibázik, a hasznos kimenet az első kiírt hiba, nem a napló utolsó húsz sora.

A munkamenet és a hálózati konfiguráció különvált

Ez a megkülönböztetés dönti el, hogy egy kapcsolat valóban szállít-e forgalmat. A TLS-munkamenet létrehozása interfészt ad a kliens oldalán. Az útvonalak, címek és DNS-feloldók alkalmazása egy második lépés, amely a hálózati szkripten keresztül történik, és egy build, amely szkript nélkül állított elő binárist, fél klienssel rendelkezik.

Ugyanez a szétválasztás magyarázza, miért viselkedik másként két gép azonos kliensekkel: a szkript a rendszer hálózati konfigurációját kérdezi meg, és ez a konfiguráció magában foglal mindent, ami útvonalat igényelt. Amikor egy osztott alagút váratlan helyre küldi a forgalmat, az alagút végzi a dolgát, és az útválasztási döntést kell megvizsgálni.

Tehát hibakereséskor kérdezze meg, melyik réteg hibázott. Az a munkamenet, amely soha nem jön létre, protokoll, tanúsítvány vagy hitelesítő adatok. Az a munkamenet, amely létrejön és semmit nem továbbít, az interfész és a szkript. Egy telepített kliens, amely egy hálózatról működik és egy másikról nem, elérhetőség, és ezen semmilyen újraépítés nem változtat.

Tudja, melyik binárist futtatja

Egy kézzel telepített build és egy csomagolt bináris békében megférhet egymás mellett, és hogy melyik fut, az az elérési útjától függ, nem a szándékaitól. Derítse ki, mielőtt verziószámot jelentene bárkinek.

which -a openconnect
openconnect --version
brew list --versions openconnect

Az első parancs felsorolja az összes példányt, amelyet a shellje lát, abban a sorrendben, ahogy próbálná őket. A második megmondja, melyik válaszolt. Amikor ez nem egyezik az elvárásaival, egy régi kísérletből származó buildet futtat, és semmilyen konfigurációváltozás nem mozdítja el.

Egy kliens telepítése nem átjáró-jóváhagyás

Egy működő bináris nem tesz egy telepítést kompatibilissé. Erősítse meg az átjáró protokollját, hitelesítési folyamatát és a felügyelt eszközre vonatkozó követelményt azokkal, akik birtokolják, mert ezek olyan szabályzat- és alkalmazásréteg-tények, amelyeket egy build nem tud szolgáltatni.

A projekt buildutasításai részletesebben tárgyalják az autotools sorrendjét és a hálózati szkript követelményét, és ezeket kell követni, nem egy blogbejegyzést, amely régebbi a macOS-kiadásánál. Ha a cél egyszerűen a csatlakozás, vegye a csomagot, tartsa meg a szkriptet, és hagyja ki a fordítót.

Kapcsolódó cikkek