Python-flater yn OpenVPN 3: reparearje it ark, net de systeem-Python

In traceback ferskynt as in VPN-behearopdracht begjint, en it earste ympuls is in oare Python te ynstallearjen of it systeemferstek earne oars hinne te wizen. Dat ympuls monget twa runtime-omjouwings trochinoar dy't neat mei elkoar te meitsjen hawwe. Ien heart by it bestjoeringssysteem en syn ferpakke ark; de oare heart by hokker projekt dan ek dat jo bouwe. It earste feroarje om it twadde te befredigjen is de manier wêrop in wurkjende burorekenmasine syn pakketbehearder ferliest.

De ferliking dy't de muoite wurdich is, is tusken it ûnderdiel dat echt mislearre en de runtime-omjouwing dy't jo it rjocht hawwe om te feroarjen. Se binne hast nea itselde objekt.

Twa Python-fragen dy't op ien lykje

De earste fraach is: hokker ynterpreter rûn it programma dat de traceback printsje liet? De twadde is: hokker ynterpreter moat myn projekt brûke? Se lykje identyk yn in terminal, omdat beide beantwurde wurde troch python3 te typen, en se hawwe ferskate eigners, ferskate upgrade-paden en ferskate ynfloedsradius.

In systeemark is bûn oan de ynterpreter dêr't syn distribúsje mei levere waard, tegearre mei de kompilearre modules dy't boud binne tsjin de ABI fan dy ynterpreter. In projekt is bûn oan hokker omjouwing jo der ek foar meitsje. It systeemferstek ferpleatse feroaret it earste foar elk ark op de masine tagelyk; in omjouwing meitsje feroaret it twadde foar ien map.

Mar ien fan dy aksjes is binnen in minút werom te draaien. It is net de earste.

Hokker ûnderdiel brocht de flater fuort

Lês de earste rigel fan de traceback en it útfierbere bestân dat dy fuortbrocht foardat jo eat oars lêze. De kommando-rigel-frontend, de privilezjearre tsjinst en de API-bindingen binne aparte stikken, en mar guon dêrfan binne hielendal 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

De earste rigel fan in skript neamt de ynterpreter dy't it brûke sil, en dat is de ynterpreter dêr't de traceback wei kaam. De pakketfraach fertelt jo wa't it bestân besit, wat beslút wa't it feroarje mei. De tsjinststatus beantwurdet in hiel oare fraach: oft de privilezjearre backend dy't echt sesjes oanmakket rint.

In module-ymportflater, in wegering fan D-Bus-aktivearring en in wegere legitimasje binne trije ferskate stadia. In ymportflater bart foardat der ek mar ien sesje is, dus gjin inkelde VPN-konfiguraasje sil dy reparearje, en in wurkjende tsjinst sil dy ek net reparearje. It berjocht yn ien fan dy trije stadia yndiele is de wiere earste stap.

Wat in projektomjouwing reparearje kin en wat net

In projektomjouwing lost in projektprobleem op: de krekte biblioteekferzjes dy't ien applikaasje nedich hat, isolearre fan al it oare. Dat is echt nuttich, en it is it rjochte ark as it mislearjende programma in skript is dat jo besitte.

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

It twadde kommando lit sjen hokker kopy fan de bindingen in opjûne ynterpreter sjen kin, wat de fluchste manier is om in ûntbrekkend pakket fan in oerskadele te ûnderskieden. Rin it mei de ynterpreter dy't it mislearjende skript brûkt, net mei in oare dy't tafallich wurket.

Wat in projektomjouwing net kin, is in troch de distribúsje ferpakt frontend reparearje. De ôfhinklikheden fan dat programma binne boud foar de ynterpreter dy't de pakketbehearder keas, en it yn de omjouwing fan jo projekt rinne lit sil of mislearje of in mingsel meitsje dat nimmen stipet. Paden der mei in omjouwingsfariabele yn spuitsje is deselde flater mei ekstra stappen: jo hawwe feroare wat it ark ladelet sûnder te feroarjen wêr't it tsjin test is. Dy ruil liket op in repaaraasje krekt sa lang as it duorret om de folgjende ymport te treffen.

Wêrom't it omlieden fan de systeemynterpreter in falstrik is

It feroarjen fan de ferstek-ynterpreter is oanloklik omdat it liket as reparearret it de traceback mei ien kommando. It brekt ek de oanname dêr't elk ferpakt Python-ark op de host op boud is, en de flaters ferskine letter en op plakken dy't der neat mei te meitsjen hawwe.

Meganismen foar alternatyfkar waarden ûntwurpen om te wikseljen tusken lykweardige ymplemintaasjes, net om in nijere taal ûnder âldere kompilearre modules te ynstallearjen. Kompilearre útwreidings wurde boud foar in spesifike ABI, dus in module dy't juster ymportearre koe hjoed net lade sûnder dat ien pakket fuorthelle is.

Der is ek in namme-falstrik yn de rie dy't minsken fine. It kommando python sûnder ferzje hat net ien universele betsjutting oer distribúsjes en omjouwings hinne, en it behannelje as in fêst synonym foar in bepaald haadferzje jout repaaraasjes dy't allinnich wurkje op de masine dêr't se skreaun binne. Lês it belied fan it systeem foar jo, net dat út de blogpost.

Aparte akseptaasjetests

Twa tests hearre oan de ein, en it slagje fan de iene seit neat oer de oare. De earste is dat it stipe klantkommando wurket mei de ynterpreter dêr't it foar ferpakt is. De twadde is dat de privilezjearre tsjinst in sesje oanmakket en de tunnel ferkear draacht.

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

Hâld in ûnôfhinklike wei nei de masine wylst jo wurkje, benammen as de VPN jo iennichste behearstagonklikheid draacht. In feroaring oan in systeemynterpreter is krekt it soarte bewurking dat dy tagong healwei fuorthelje kin.

As de flater in ûntbrekkende module foar in systeemark is, is de korreksje in pakketoperaasje fia de stipe wurkstream. As de flater in ferzjekonflikt yn jo eigen projekt is, is de korreksje in omjouwing. Kieze tusken dy twa is de hiele beslissing, en dy wurdt besletten troch hokker programma de traceback printsje liet.