Python-eraro en OpenVPN 3: riparu la ilon, ne la sisteman Python

Spurado aperas, kiam VPN-administra komando ekstartas, kaj la unua instinkto estas instali alian Python aŭ montrigi la sisteman defaŭlton aliloken. Tiu instinkto miksas du rulmediaĵojn, kiuj havas nenion komunan. Unu apartenas al la operaciumo kaj al ĝiaj pakitaj iloj; la alia apartenas al kiu ajn projekto, kiun vi konstruas. Ŝanĝi la unuan por kontentigi la duan estas la maniero, per kiu funkcianta labortablo perdas sian pakaĵmastrumilon.

La komparo inda estas inter la komponanto, kiu efektive fiaskis, kaj la rulmedio, kiun vi rajtas ŝanĝi. Ili preskaŭ neniam estas la sama objekto.

Du demandoj pri Python, kiuj aspektas kiel unu

La unua demando estas: kiu interpretilo ruligis la programon, kiu presis la spuraron? La dua estas: kiun interpretilon mia projekto uzu? Ili aspektas identaj en terminalo, ĉar al ambaŭ oni respondas tajpante python3, kaj ili havas malsamajn posedantojn, malsamajn ĝisdatigvojojn kaj malsamajn efikradiusojn.

Sistema ilo estas ligita al la interpretilo, kun kiu ĝia distribuaĵo estis liverita, kune kun la kompilitaj moduloj konstruitaj kontraŭ la ABI de tiu interpretilo. Projekto estas ligita al kiu ajn medio, kiun vi kreas por ĝi. Movi la sisteman defaŭlton ŝanĝas la unuan por ĉiu ilo en la maŝino samtempe; krei medion ŝanĝas la duan por unu dosierujo.

Nur unu el tiuj agoj estas reigebla en unu minuto. Ĝi ne estas la unua.

Kiu komponanto produktis la eraron

Legu la unuan linion de la spurado kaj la plenumeblon, kiu produktis ĝin, antaŭ ol legi ion ajn alian. La komandlinia fasondo, la privilegiita servo kaj la API-ligiloj estas apartaj pecoj, kaj nur kelkaj el ili entute estas 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

La unua linio de skripto nomas la interpretilon, kiun ĝi uzos, kaj el tiu interpretilo venis la spurado. La pakaĵdemando diras al vi, kiu posedas la dosieron, kio decidas, kiu rajtas ŝanĝi ĝin. La servostato respondas tute alian demandon: ĉu la privilegiita malantaŭaĵo, kiu efektive starigas sesiojn, funkcias.

Modul-enporta eraro, rifuzo de D-Bus-aktivigo kaj rifuzita legitimilo estas tri malsamaj etapoj. Enporta eraro okazas antaŭ ol ekzistas ajna sesio, do neniu VPN-agordo ĝin riparos, kaj funkcianta servo ankaŭ ne riparos ĝin. Ordigo de la mesaĝo en unu el tiuj tri etapoj estas la efektiva unua paŝo.

Kion projekta medio povas ripari kaj kion ne

Projekta medio solvas projektan problemon: la precizajn bibliotekversiojn, kiujn unu aplikaĵo bezonas, izolitajn de ĉio alia. Tio vere utilas, kaj ĝi estas la ĝusta ilo, kiam la fiaska programo estas skripto, kiun vi posedas.

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

La dua komando montras, kiun kopion de la ligiloj difinita interpretilo vidas, kio estas la plej rapida maniero distingi mankan pakaĵon de ombrumita. Rulu ĝin per la interpretilo, kiun uzas la fiaska skripto, ne per alia, kiu hazarde funkcias.

Kion projekta medio ne povas fari, estas ripari distribuan pakaĵan fasondon. La dependaĵoj de tiu programo estis konstruitaj por la interpretilo, kiun la pakaĵmastrumilo elektis, kaj ruli ĝin en la medio de via projekto aŭ fiaskas aŭ produktas miksaĵon, kiun neniu subtenas. Enŝprucigi vojojn en ĝin per medivariablo estas la sama eraro kun pliaj paŝoj: vi ŝanĝis, kion la ilo ŝargas, sen ŝanĝi, kontraŭ kio ĝi estis testita. Tiu interŝanĝo aspektas kiel riparo ekzakte tiom longe, kiom necesas por trafi la sekvan enporton.

Kial alidirekti la sisteman interpretilon estas kaptilo

Ŝanĝi la defaŭltan interpretilon allogas, ĉar ĝi ŝajnas ripari la spuraron per unu komando. Ĝi ankaŭ rompas la supozon, sur kiu ĉiu pakaĵa Python-ilo en la gastiganto estis konstruita, kaj la fiaskoj aperas poste kaj en ne rilataj lokoj.

Mekanismoj por elekto de alternativoj estis dizajnitaj por ŝalti inter ekvivalentaj realigoj, ne por instali pli novan lingvon sub pli malnovaj kompilitaj moduloj. Kompilitaj etendaĵoj estas konstruitaj por specifa ABI, do modulo enportita hieraŭ povas malsukcesi ŝargi hodiaŭ, sen ke eĉ unu pakaĵo estis forigita.

Estas ankaŭ nomkaptilo en la konsilo, kiun homoj trovas. La senversia komando python ne havas unu universalan signifon trans distribuaĵoj kaj medioj, kaj trakti ĝin kiel fiksan sinonimon por certa ĉefa versio produktas riparojn, kiuj funkcias nur sur la maŝino, kie ili estis skribitaj. Legu la regularon de la sistemo antaŭ vi, ne tiun en la blogaĵo.

Apartaj akceptotestoj

Fine devus esti du testoj, kaj trapasi unu diras nenion pri la alia. La unua estas, ke la subtenata klienta komando funkcias kun la interpretilo, por kiu ĝi estis pakaĵita. La dua estas, ke la privilegiita servo starigas sesion kaj la tunelo portas trafikon.

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

Konservu sendependan vojon en la maŝinon, dum vi laboras, precipe se la VPN portas vian solan administran aliron. Ŝanĝo al sistema interpretilo estas ĝuste tia redakto, kiu povas forpreni tiun aliron duonvoje.

Se la fiasko estas mankanta modulo por sistema ilo, la korekto estas paka operacio tra la subtenata laborfluo. Se la fiasko estas versia konflikto en via propra projekto, la korekto estas medio. Elekti inter tiuj du estas la tuta decido, kaj ĝin decidas, kiu programo presis la spuraron.