Gabim Python në OpenVPN 3: rregullo mjetin, jo Python-in e sistemit

Traceback shfaqet kur nis një komandë e administrimit të VPN-së, dhe instinkti i parë vrapon drejt instalimit të një Python-i tjetër ose drejtimit të paracaktuar të sistemit diku tjetër. Ai instinkt përzien dy runtime që nuk kanë asgjë të përbashkët. Njëri i përket sistemit operativ dhe mjeteve të tij të paketuara; tjetri i përket çdo projekti që po ndërtoni. Të ndryshosh të parin për të kënaqur të dytin është mënyra se si një desktop që punon humbet menaxherin e paketave.

Krahasimi që ia vlen të bëhet është midis komponentit që dështoi vërtet dhe runtime-it që ju keni të drejtë të ndryshoni. Ata pothuajse kurrë nuk janë i njëjti objekt.

Dy pyetje rreth Python që duken si një

Pyetja e parë është: cili përkthyes ekzekutoi programin që shtypi traceback-un? E dyta është: cili përkthyes duhet të përdorë projekti im? Në një terminal duken identike, sepse të dyja përgjigjen duke shtypur python3, dhe kanë pronarë të ndryshëm, rrugë përditësimi të ndryshme dhe rreze të ndryshme ndikimi.

Një mjet sistemi është i lidhur me përkthyesin me të cilin e dha shpërndarja, së bashku me modulet e përpiluara të ndërtuara për ABI-në e atij përkthyesi. Një projekt është i lidhur me çdo mjedis që krijoni për të. Zhvendosja e paracaktuar e sistemit ndryshon të parin për çdo mjet në makinë përnjëherë; krijimi i një mjedisi ndryshon të dytin për një drejtori të vetme.

Vetëm njëri prej atyre veprimeve është i kthyeshëm brenda një minute. Nuk është i pari.

Cili komponent e prodhoi gabimin

Lexoni rreshtin e parë të traceback-ut dhe skedarin ekzekutues që e prodhoi përpara se të lexoni çdo gjë tjetër. Frontend-i i rreshtit të komandës, shërbimi i privilegjuar dhe lidhjet e API-së janë pjesë të veçanta, dhe vetëm disa prej tyre janë fare 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

Rreshti i parë i një skripti emërton përkthyesin që do të përdorë, dhe pikërisht prej atij përkthyesi erdhi traceback-u. Kërkimi i paketës ju tregon kujt i përket skedari, gjë që përcakton kush lejohet ta ndryshojë. Statusi i shërbimit i përgjigjet një pyetjeje krejt tjetër: nëse backend-i i privilegjuar që hap vërtet sesionet është duke punuar.

Një gabim importimi moduli, një refuzim i aktivizimit D-Bus dhe një kredencial i refuzuar janë tre faza të ndryshme. Gabimi i importimit ndodh para se të ekzistojë çdo sesion, prandaj asnjë sasi konfigurimi VPN nuk e rregullon, dhe as një shërbim që punon nuk e rregullon. Klasifikimi i mesazhit në njërën prej atyre tre fazave është hapi i parë i vërtetë.

Çfarë mjedisi i projektit mund dhe nuk mund të rregullojë

Një mjedis projekti zgjidh një problem projekti: versionet e sakta të bibliotekave që i duhen një aplikacioni, të izoluara nga gjithçka tjetër. Kjo është vërtet e dobishme, dhe është mjeti i duhur kur programi që dështon është një skript i juaji.

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

Komanda e dytë tregon se cilën kopje të lidhjeve sheh një përkthyes i caktuar, dhe kjo është mënyra më e shpejtë për të dalluar një paketë që mungon nga një paketë e hijezuar. Ekzekutojeni me përkthyesin që përdor skripti që dështon, jo me një tjetër që punon rastësisht.

Ajo që një mjedis projekti nuk mund të bëjë është të rregullojë një frontend të paketuar nga shpërndarja. Varësitë e atij programi u ndërtuan për përkthyesin që zgjodhi menaxheri i paketave, dhe ekzekutimi i tij brenda mjedisit të projektit tuaj ose dështon ose prodhon një përzierje që askush nuk e mbështet. Injektimi i shtigjeve në të me një ndryshore mjedisi është i njëjti gabim me hapa shtesë: keni ndryshuar atë që mjeti ngarkon pa ndryshuar atë kundër të cilit u testua. Ai shkëmbim duket si rregullim saktësisht deri sa të mbërrihet importimi tjetër.

Pse ridrejtimi i përkthyesit të sistemit është kurth

Ndryshimi i përkthyesit të paracaktuar është tërheqës sepse duket se e rregullon traceback-un me një komandë të vetme. Ai gjithashtu thyen supozimin mbi të cilin u ndërtua çdo mjet Python i paketuar në host, dhe dështimet shfaqen më vonë dhe në vende të palidhura.

Mekanizmat e zgjedhjes së alternativës u krijuan për të kaluar midis implementimeve ekuivalente, jo për të instaluar një gjuhë më të re nën module të përpiluara më të vjetra. Zgjerimet e përpiluara ndërtohen për një ABI të caktuar, kështu që një modul që u importua dje mund të mos ngarkohet sot pa u hequr asnjë paketë.

Ka edhe një kurth emri në këshillat që njerëzit gjejnë. Komanda python pa version nuk ka një kuptim universal midis shpërndarjeve dhe mjediseve, dhe trajtimi i saj si sinonim fiks i një versioni të caktuar kryesor prodhon rregullime që punojnë vetëm në makinën ku u shkruan. Lexoni politikën e sistemit përpara jush, jo atë në shkrimin e blogut.

Teste pranimi të ndara

Në fund vijnë dy teste, dhe kalimi i njërit nuk thotë asgjë për tjetrin. I pari është që komanda e klientit e mbështetur punon me përkthyesin për të cilin u paketua. I dyti është që shërbimi i privilegjuar vendos një sesion dhe tuneli mbart trafikun.

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

Mbani një rrugë të pavarur për në makinë ndërsa punoni, sidomos nëse VPN-ja mbart aksesin tuaj të vetëm administrativ. Një ndryshim në një përkthyes sistemi është pikërisht lloji i redaktimit që mund ta heqë atë akses në gjysmë të rrugës.

Nëse dështimi është një modul që mungon për një mjet sistemi, rregullimi është një operacion pakete përmes rrjedhës së punës së mbështetur. Nëse dështimi është një konflikt versionesh në projektin tuaj, rregullimi është një mjedis. Zgjedhja midis të dyve është e gjithë vendimi, dhe vendoset nga cili program shtypi traceback-un.