Error sa Python ng OpenVPN 3: ayusin ang tool, hindi ang system Python

Lumilitaw ang traceback kapag nagsisimula ang isang command sa pamamahala ng VPN, at ang unang instinct ay tumatakbo sa pag-install ng ibang Python o pagturo sa default ng system sa ibang lugar. Hinahalo ng instinct na iyon ang dalawang runtime na walang kinalaman sa isa't isa. Ang isa ay pag-aari ng operating system at ng mga naka-package na tool nito; ang isa pa ay pag-aari ng anumang proyektong ginagawa mo. Ang baguhin ang una para masiyahan ang pangalawa ay kung paano nawawala ng gumaganang desktop ang package manager nito.

Ang paghahambing na sulit gawin ay sa pagitan ng component na talagang nabigo at ng runtime na may karapatan kang baguhin. Halos hindi sila kailanman ang parehong bagay.

Dalawang tanong sa Python na mukhang isa

Ang unang tanong ay: aling interpreter ang nagpatakbo ng program na nag-print ng traceback? Ang pangalawa ay: aling interpreter ang dapat gamitin ng aking proyekto? Sa terminal ay magkapareho sila, dahil pareho silang sinasagot sa pamamagitan ng pag-type ng python3, at may magkaibang may-ari, magkaibang landas ng upgrade at magkaibang saklaw ng epekto.

Ang tool ng system ay nakatali sa interpreter na kasama ng distribution nito, kasama ang mga compiled module na ginawa para sa ABI ng interpreter na iyon. Ang proyekto ay nakatali sa anumang environment na ginawa mo para dito. Ang ilipat ang default ng system ay binabago ang una para sa bawat tool sa machine nang sabay; ang lumikha ng environment ay binabago ang pangalawa para sa isang direktoryo.

Isa lang sa mga aksyon na iyon ang maibabalik sa loob ng isang minuto. Hindi ito ang una.

Aling component ang gumawa ng error

Basahin ang unang linya ng traceback at ang executable na gumawa nito bago magbasa ng anupamang iba. Ang frontend sa command line, ang privileged service at ang mga API binding ay magkakaibang bahagi, at ilan lamang sa kanila ang 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

Ang unang linya ng script ay nagpapangalan sa interpreter na gagamitin nito, at mula sa interpreter na iyon nagmula ang traceback. Sinasabi ng query sa package kung kanino ang file, na siyang nagtatakda kung sino ang pinapayagang magbago nito. Ang status ng service ay sumasagot sa ganap na ibang tanong: kung tumatakbo ang privileged backend na talagang nagbubukas ng mga session.

Ang error sa pag-import ng module, isang pagtanggi sa D-Bus activation at isang tinanggihang credential ay tatlong magkaibang yugto. Ang error sa pag-import ay nangyayari bago pa man umiral ang anumang session, kaya wala sa dami ng VPN configuration ang makakaayos nito, at wala rin itong maaayos ng gumaganang service. Ang mailagay ang mensahe sa isa sa tatlong yugtong iyon ay ang tunay na unang hakbang.

Ano ang kaya at hindi kaya ayusin ng environment ng proyekto

Ang environment ng proyekto ay lumulutas ng problema ng proyekto: ang eksaktong bersyon ng library na kailangan ng isang application, hiwalay sa lahat ng iba. Tunay na kapaki-pakinabang iyon, at ito ang tamang tool kapag ang programang nabibigo ay sarili mong script.

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

Ang pangalawang command ay nagpapakita kung aling kopya ng binding ang nakikita ng isang partikular na interpreter, at iyon ang pinakamabilis na paraan upang makilala ang nawawalang package sa isang nalilimang package. Patakbuhin ito gamit ang interpreter na ginagamit ng nabibigong script, hindi gamit ang iba na nagkataong gumagana.

Ang hindi kaya ng environment ng proyekto ay ayusin ang frontend na naka-package ng distribution. Ang mga dependency ng programang iyon ay ginawa para sa interpreter na pinili ng package manager, at ang pagpapatakbo nito sa loob ng environment ng iyong proyekto ay alinman sa nabibigo o gumagawa ng halo na walang sinumang sumusuporta. Ang mag-inject ng mga path dito gamit ang environment variable ay ang parehong pagkakamali na may dagdag na hakbang: binago mo ang nilo-load ng tool nang hindi binabago ang sinubukan laban dito. Ang palitang iyon ay mukhang pag-aayos nang eksaktong kasing tagal ng pag-abot sa susunod na import.

Bakit bitag ang pagturo ng system interpreter sa iba

Ang baguhin ang default na interpreter ay kaakit-akit dahil mukhang inaayos nito ang traceback sa isang command. Sinisira rin nito ang palagay na pinagbatayan ng bawat naka-package na Python tool sa host, at ang mga pagpalya ay lumilitaw mamaya at sa mga walang kaugnayang lugar.

Ang mga mekanismo sa pagpili ng alternatibo ay ginawa upang lumipat sa pagitan ng magkatumbas na implementasyon, hindi upang mag-install ng mas bagong wika sa ilalim ng mas lumang compiled module. Ang mga compiled extension ay ginagawa para sa isang partikular na ABI, kaya ang isang module na na-import kahapon ay maaaring mabigong mag-load ngayon nang walang kahit isang package na natanggal.

May bitag din sa pangalan sa mga payo na nakikita ng mga tao. Ang command na python na walang bersyon ay walang isang pangkalahatang kahulugan sa mga distribution at environment, at ang ituring itong fixed na kasingkahulugan ng isang partikular na major version ay nagbibigay ng mga pag-aayos na gumagana lamang sa machine kung saan isinulat ang mga ito. Basahin ang patakaran ng system sa harap mo, hindi ang nasa post ng blog.

Hiwalay na mga pagsubok sa pagtanggap

Sa dulo ay nararapat ang dalawang test, at ang pagpasa sa isa ay walang sinasabi tungkol sa isa pa. Ang una ay gumagana ang sinusuportahang client command sa interpreter na pinag-package-an nito. Ang pangalawa ay nagtatatag ng session ang privileged service at nagdadala ng trapiko ang tunnel.

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

Panatilihin ang isang malayang daan papasok sa machine habang nagtatrabaho ka, lalo na kung ang VPN ang nagdadala ng tanging administrative access mo. Ang pagbabago sa isang system interpreter ay eksaktong uri ng edit na maaaring mag-alis ng access na iyon sa kalagitnaan.

Kung ang pagpalya ay nawawalang module para sa isang tool ng system, ang pagwawasto ay operasyon sa package sa pamamagitan ng sinusuportahang workflow. Kung ang pagpalya ay salungatan ng bersyon sa sarili mong proyekto, ang pagwawasto ay environment. Ang pumili sa pagitan ng dalawa ay ang buong desisyon, at ito ay pinagpapasyahan ng kung aling program ang nag-print ng traceback.