Python-feil i OpenVPN 3: reparer verktøyet, ikkje system-Python

Ein traceback dukkar opp når ein VPN-administrasjonskommando startar, og den første innskota går mot å installere ein annan Python eller peike systemstandarden ein annan stad. Den innskota blandar to køyretider som ikkje har noko med kvarandre å gjere. Éi høyrer til operativsystemet og dei pakka verktøya; den andre høyrer til kva som helst prosjekt du byggjer. Å endre den første for å tilfredsstille den andre er korleis ein fungerande skrivebord mistar pakkehandsamaren sin.

Samanlikninga som er verdt å gjere, er mellom komponenten som faktisk feila og køyretida du har rett til å endre. Dei er nesten aldri same objektet.

To Python-spørsmål som ser ut som eitt

Det første spørsmålet er: kva tolk køyrde programmet som skreiv ut tracebacken? Det andre er: kva tolk skal prosjektet mitt bruke? Dei ser identiske ut i ein terminal fordi begge blir svara på ved å skrive python3, og dei har ulike eigarar, ulike oppgraderingsvegar og ulik eksplosjonsradius.

Eit systemverktøy er bunde til tolken distribusjonen sende det med, saman med dei kompilerte modulane som er bygde mot ABI-en til den tolken. Eit prosjekt er bunde til kva som helst miljø du lagar for det. Å flytte systemstandarden endrar den første for kvart verktøy på maskinen på ein gong; å lage eit miljø endrar den andre for éin katalog.

Berre éi av desse handlingane kan gjerast om på eitt minutt. Det er ikkje den første.

Kva komponent produserte feilen

Les den første linja i tracebacken og den køyrbare fila som produserte han, før du les noko anna. Frontendet på kommandolinja, den privilegerte tenesta og API-bindingane er separate delar, og berre nokre av dei er Python i det heile.

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

Den første linja i eit skript namngjev tolken det skal bruke, og det er tolken tracebacken kom frå. Pakkespurnaden fortel deg kven som eig fila, noko som avgjer kven som har lov til å endre henne. Tenestestatusen svarar på eit heilt anna spørsmål: om den privilegerte backend-en som faktisk opnar sesjonar, køyrer.

Ein modulimportfeil, ei avvising av D-Bus-aktivering og ein avvist legitimasjon er tre ulike stadium. Ein importfeil skjer før nokon sesjon finst, så inga mengd VPN-konfigurasjon vil rette han, og ei fungerande teneste vil heller ikkje rette han. Å sortere meldinga inn i eitt av desse tre stadia er det eigentlege første steget.

Kva eit prosjektmiljø kan og ikkje kan rette

Eit prosjektmiljø løyser eit prosjektproblem: dei eksakte bibliotekversjonane éin applikasjon treng, isolerte frå alt anna. Det er verkeleg nyttig, og det er det rette verktøyet når programmet som feilar, er eit skript du eig.

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

Den andre kommandoen viser kva kopi av bindingane ein gjeven tolk kan sjå, og det er den snøggaste måten å skilje ein manglande pakke frå ein skyggelagd pakke. Køyr han med tolken skriptet som feilar brukar, ikkje med ein annan som tilfeldigvis verkar.

Det eit prosjektmiljø ikkje kan gjere, er å reparere eit frontend som distribusjonen har pakka. Avhengnadene til det programmet vart bygde for tolken pakkehandsamaren valde, og å køyre det inne i prosjektmiljøet ditt feilar anten eller gjev ei blanding ingen støttar. Å sprøyte stiar inn i det med ein miljøvariabel er same feilen med ekstra steg: du har endra kva verktøyet lastar inn utan å endre kva det er testa mot. Den byttehandelen ser ut som ei retting nøyaktig så lenge det tek å treffe neste import.

Kvifor det er ei felle å peike systemtolken om

Å endre standardtolken er freistande fordi det ser ut til å rette tracebacken med éin kommando. Det bryt også føresetnaden kvart pakka Python-verktøy på verten vart bygt på, og feila dukkar opp seinare og på urelaterte stader.

Alternativveljarane vart laga for å bytte mellom likeverdige implementasjonar, ikkje for å installere eit nyare språk under eldre kompilerte modular. Kompilerte utvidingar blir bygde for ein bestemt ABI, så ein modul som vart importert i går, kan i dag feile på lasting utan at éin pakke er fjerna.

Det er også ei namnefelle i råda folk finn. Kommandoen python utan versjon har ikkje éin universell tyding på tvers av distribusjonar og miljø, og å handsame han som eit fast synonym for ein bestemt hovudversjon gjev rettingar som berre verkar på maskinen der dei vart skrivne. Les policyen til systemet framfor deg i staden for den i blogginnlegget.

Skilde akseptansetestar

To testar høyrer heime på slutten, og å stå éin seier ingenting om den andre. Den første er at den støtta klientkommandoen verkar med tolken han vart pakka for. Den andre er at den privilegerte tenesta opprettar ein sesjon og tunnelen fraktar trafikk.

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

Hald ein uavhengig veg inn på maskinen medan du arbeider, særleg om VPN-en fraktar din einaste administrative tilgang. Ei endring av ein systemtolk er nettopp den typen redigering som kan fjerne den tilgangen halvvegs.

Om feilen er ein manglande modul for eit systemverktøy, er rettinga ein pakkeoperasjon gjennom den støtta arbeidsflyten. Om feilen er ein versjonskonflikt i ditt eige prosjekt, er rettinga eit miljø. Å velje mellom dei to er heile avgjerda, og ho blir avgjort av kva program som skreiv ut tracebacken.