Melyik OpenVPN-csomagot tudja egy Linux-kiadás valóban támogatni

A konkrét OpenVPN-kiadást megnevező utasítások általában egy funkciót kódolnak, és a verziószám csak a helyettesítője annak. Mire elolvassa őket, a disztribúció már adhat a megnevezett verziónál újabbat, és mégis hiányozhat belőle a szükséges integráció, vagy adhat nála régebbit, amely már lefedi a követelményt. Ha a számot célnak tekinti, olyan tárolómódosítások születnek, amelyek semmit sem oldanak meg. Ha egy követelmény tünetének tekinti, sokkal kisebb döntés születik.

Három kérdés választja el a kettőt: melyik megvalósítás, melyik alapkiadás, és ki felel a frissítésekért.

A verziószám nem funkciókövetelmény

Előbb kérdezze meg, mire van szüksége a kapcsolatnak, és csak utána, melyik csomag biztosítja. Egy profil igényelhet titkosítást, TLS-módot, hitelesítési bővítményt vagy kezelőfelületet, és ezek bármelyike hiányozhat egy olyan buildből, amely kielégítő verziószöveget jelent. Fordítva, egy kissé régebbi build is megvalósíthat mindent, amit a profil használ. A verziószöveg a csomagoló által írt összefoglaló, nem funkciólista.

Tisztázza, hogy az utasítás azt jelenti-e, hogy „ez a funkció vagy újabb”, vagy azt, hogy „pontosan ezt a buildet tesztelték”. A két válasz különböző tárolókhoz vezet.

A kódnévnek egyeznie kell az alapkiadással

A tárolókat a disztribúció kódneve szerint kulcsolják, és egy származtatott kiadás neve nem az alapja kódneve. A /etc/os-release fájlból olvassa ki a VERSION_CODENAME és ID_LIKE értéket, majd erősítse meg, melyik alapkiadást követi a származtatott. Egy régi válasz, amely egy asztali kiadást egyetlen Ubuntu-kódnévhez rendelt, semmit sem mond a következőről. A kódnév találgatása az az út, amelyen a rendszer végül egy másik C-könyvtárhoz épített csomagokat húz be.

Még bármi hozzáadása előtt nézze meg a apt-cache policy openvpn paranccsal, mit kínál már a csomagkezelő. Ha a telepített jelölt kielégíti a követelményt, a tároló kérdése eltűnik.

Mihez kötődik valójában egy upstream tároló

Az upstream csatorna adott alapkiadásokhoz publikál buildeket, és az utasításai tárolósort párosítanak egy aláírókulccsal és egy támogatott kódnévvel. Ezek a részek nem helyőrzők, amelyeket bármely ismert kódnévre cserélhet. A függőségeket ahhoz a kiadáshoz oldják fel, amelyre a build irányult, ezért egy tisztán települő csomag is elronthat egy könyvtárat megosztó, nem kapcsolódó szoftvert.

Olvassa el a választott megvalósítás tárolóútmutatóját, és kövesse annak jelenlegi kompatibilitási táblázatát egy régebbi blog másolata helyett.

A telepítés nem integrálás

A openvpn bináris lecserélése nem ad hozzá hiányzó NetworkManager-bővítményt, importpárbeszédet vagy asztali szerkesztőt. Ezek külön csomagokban élnek, mint a network-manager-openvpn és asztali megfelelője, és saját verzióviszonyuk van az ügyfélkönyvtárhoz. Az OpenVPN 3 Linux megint másik megvalósítás, saját munkamenet- és konfigurációs modellel, ezért a csomagjai nem közvetlen helyettesítői egy 2.x profilú munkafolyamatnak.

Döntse el, melyik összetevő birtokolja a futó alagutat, mielőtt bármit telepít. Két kezelő egy gazdagépen ugyanazt a kettős alagút zavart kelti, mint két kliens.

Írja le a három döntést

Rögzítse a megvalósítást, az alapkiadást és a frissítések felelősét, és jegyezze fel, melyikük várhatóan változik. Ezt a feljegyzést olvassa egy jövőbeli frissítés, amikor a tárolósor egy disztribúció-kiadás után felmondja a működést. Nélküle a következő ember megismétli a kódnév találgatását egy újabb számmal.

Ha a szükséges csatorna már nem támogatja az alapkiadást, a válasz platformátállás, nem egy három kiadással ezelőtti tároló.