Python-hiba az OpenVPN 3-ban: az eszközt javítsd, ne a rendszer Pythont

Egy traceback jelenik meg, amikor elindul egy VPN-kezelő parancs, és az első ösztön az, hogy telepítsünk egy másik Pythont, vagy a rendszer alapértelmezését irányítsuk máshová. Ez az ösztön két olyan futtatókörnyezetet kever össze, amelyeknek semmi közük egymáshoz. Az egyik az operációs rendszerhez és annak csomagolt eszközeihez tartozik; a másik ahhoz a projekthez, amelyet építesz. Az elsőt a második kedvéért megváltoztatni az az út, amelyen egy működő asztali gép elveszíti a csomagkezelőjét.

Az összehasonlítás, amelyet érdemes megtenni, a valóban meghibásodott komponens és a módosítható futtatókörnyezet között van. Szinte soha nem ugyanaz az objektum.

Két Python-kérdés, amely egynek látszik

Az első kérdés: melyik értelmező futtatta azt a programot, amely kiírta a tracebacket? A második: melyik értelmezőt használja a projektem? A terminálban azonosnak tűnnek, mert mindkettőre python3 beírásával válaszolunk, és különböző tulajdonosaik, frissítési útvonalaik és hatáskörük van.

Egy rendszereszköz ahhoz az értelmezőhöz kötődik, amellyel a disztribúciója szállította, valamint azokhoz a fordított modulokhoz, amelyeket ennek az értelmezőnek az ABI-ja ellen építettek. Egy projekt ahhoz a környezethez kötődik, amelyet létrehozol neki. A rendszer alapértelmezésének elmozdítása az elsőt egyszerre változtatja meg a gép minden eszközénél; egy környezet létrehozása a másodikat egyetlen könyvtárnál.

E műveletek közül csak egy visszafordítható egy percen belül. Nem az első.

Melyik komponens produkálta a hibát

Olvasd el a traceback első sorát és az őt produkáló futtatható fájlt, mielőtt bármi mást olvasnál. A parancssori frontend, a kiemelt szolgáltatás és az API-kötések külön darabok, és közülük csak néhány Python.

command -v openvpn3
head -n 1 "$(command -v openvpn3)"
dpkg -S "$(command -v openvpn3)" 2>/dev/null
systemctl status openvpn3-service-client --no-pager

Egy szkript első sora megnevezi az értelmezőt, amelyet használni fog, és a traceback ebből az értelmezőből származik. A csomag-lekérdezés megmondja, kié a fájl, ami eldönti, ki jogosult módosítani. A szolgáltatás állapota egészen más kérdésre válaszol: fut-e az a kiemelt háttér, amely valóban létrehozza a munkameneteket.

Egy modulimport-hiba, egy D-Bus-aktiválás elutasítása és egy elutasított hitelesítő adat három különböző szakasz. Az importálási hiba még bármilyen munkamenet létezése előtt történik, ezért semmilyen VPN-konfiguráció nem javítja meg, és egy működő szolgáltatás sem javítja meg. Az üzenet besorolása e három szakasz valamelyikébe az igazi első lépés.

Mit tud és mit nem tud megjavítani egy projektkörnyezet

A projektkörnyezet egy projekt problémáját oldja meg: az egy alkalmazás által igényelt pontos könyvtárverziókat, minden mástól elkülönítve. Ez valóban hasznos, és ez a megfelelő eszköz, ha a meghibásodó program a saját szkripted.

uv run --python 3.11 app.py
python3 -c 'import openvpn3; print(openvpn3.__file__)'

A második parancs megmutatja, hogy egy adott értelmező a kötések melyik példányát látja, ami a leggyorsabb módja a hiányzó csomag és az árnyékolt csomag megkülönböztetésének. Azzal az értelmezővel futtasd, amelyet a meghibásodó szkript használ, ne egy másikkal, amely véletlenül működik.

Amit egy projektkörnyezet nem tud megtenni, az a disztribúció által csomagolt frontend megjavítása. Annak a programnak a függőségei ahhoz az értelmezőhöz épültek, amelyet a csomagkezelő választott, és a projektkörnyezetedben való futtatása vagy meghiúsul, vagy olyan keveréket hoz létre, amelyet senki sem támogat. Elérési utak befecskendezése környezeti változóval ugyanaz a hiba extra lépésekkel: megváltoztattad, mit tölt be az eszköz, anélkül hogy megváltoztattad volna, mihez képest tesztelték. Ez a csere pontosan addig látszik javításnak, amíg a következő importálásba nem ütközöl.

Miért csapda a rendszer értelmezőjének átirányítása

Az alapértelmezett értelmező módosítása vonzó, mert úgy tűnik, egyetlen paranccsal javítja a tracebacket. Ugyanakkor megtöri azt a feltevést, amelyre a gazdagépen minden csomagolt Python-eszköz épült, és a hibák később, összefüggéstelen helyeken jelennek meg.

Az alternatívaválasztó mechanizmusokat egyenértékű implementációk közti váltásra tervezték, nem arra, hogy újabb nyelvet telepítsenek régebbi fordított modulok alá. A fordított kiterjesztések adott ABI-hoz épülnek, így egy tegnap importált modul ma már nem töltődik be, akár egyetlen csomag eltávolítása nélkül.

Az emberek által talált tanácsban névcsapda is van. A verzió nélküli python parancsnak nincs egyetlen univerzális jelentése a disztribúciók és környezetek között, és ha egy adott főverzió rögzített szinonimájaként kezeljük, olyan javításokat kapunk, amelyek csak azon a gépen működnek, ahol írták őket. A rendszer szabályzatát olvasd, amely előtted van, ne a blogbejegyzését.

Külön elfogadási tesztek

A végén két tesztnek kell lennie, és az egyik átlépése semmit sem mond a másikról. Az első, hogy a támogatott ügyfélparancs működik azzal az értelmezővel, amelyhez csomagolták. A második, hogy a kiemelt szolgáltatás létrehoz egy munkamenetet, és a tunnel forgalmat szállít.

openvpn3 sessions-list
openvpn3-service-client --help 2>/dev/null | head -n 3
ip -4 addr show tun0

Miközben dolgozol, tarts fenn egy független utat a gépre, különösen ha a VPN hordozza az egyetlen adminisztratív hozzáférésedet. A rendszer értelmezőjének módosítása pontosan az a fajta szerkesztés, amely félúton elveheti ezt a hozzáférést.

Ha a hiba egy rendszereszköz hiányzó modulja, a javítás egy csomagművelet a támogatott munkafolyamaton keresztül. Ha a hiba a saját projektedben fellépő verzióütközés, a javítás egy környezet. A kettő közötti választás a teljes döntés, és azt az határozza meg, melyik program írta ki a tracebacket.