Python-feil i OpenVPN 3: reparer verktøyet, ikke systemets Python

En traceback dukker opp når en VPN-administrasjonskommando starter, og den første innskytelsen går mot å installere en annen Python eller peke systemets standard et annet sted. Den innskytelsen blander to kjøretider som ikke har noe med hverandre å gjøre. Én tilhører operativsystemet og de pakkede verktøyene; den andre tilhører hvilket som helst prosjekt du bygger. Å endre den første for å tilfredsstille den andre er hvordan et fungerende skrivebord mister pakkebehandleren sin.

Sammenligningen som er verdt å gjøre, er mellom komponenten som faktisk feilet og kjøretiden du har rett til å endre. De er nesten aldri samme objekt.

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

Det første spørsmålet er: hvilken tolk kjørte programmet som skrev ut tracebacken? Det andre er: hvilken tolk skal prosjektet mitt bruke? De ser identiske ut i en terminal fordi begge besvares ved å skrive python3, og de har ulike eiere, ulike oppgraderingsveier og ulik eksplosjonsradius.

Et systemverktøy er bundet til tolken distribusjonen sendte det med, sammen med de kompilerte modulene som er bygget mot den tolkens ABI. Et prosjekt er bundet til hvilket som helst miljø du lager for det. Å flytte systemets standard endrer den første for hvert verktøy på maskinen på én gang; å lage et miljø endrer den andre for én katalog.

Bare én av disse handlingene kan reverseres på et minutt. Det er ikke den første.

Hvilken komponent produserte feilen

Les den første linjen i tracebacken og den kjørbare filen som produserte den, før du leser noe annet. Frontendet på kommandolinjen, den privilegerte tjenesten og API-bindingene er separate deler, og bare noen av dem er Python i det hele tatt.

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 linjen i et skript navngir tolken det skal bruke, og det er tolken tracebacken kom fra. Pakkespørringen forteller deg hvem som eier filen, noe som avgjør hvem som har lov til å endre den. Tjenestestatusen svarer på et helt annet spørsmål: om den privilegerte backenden som faktisk oppretter sesjoner, kjører.

En modulimportfeil, en avvist D-Bus-aktivering og en avvist legitimasjon er tre forskjellige stadier. En importfeil skjer før noen sesjon finnes, så ingen mengde VPN-konfigurasjon vil rette den, og en fungerende tjeneste vil heller ikke rette den. Å sortere meldingen inn i ett av disse tre stadiene er det egentlige første steget.

Hva et prosjektmiljø kan og ikke kan rette

Et prosjektmiljø løser et prosjektproblem: de eksakte bibliotekversjonene én applikasjon trenger, isolert fra alt annet. Det er virkelig nyttig, og det er det riktige verktøyet når programmet som feiler, er et skript du eier.

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

Den andre kommandoen viser hvilken kopi av bindingene en gitt tolk kan se, og det er den raskeste måten å skille en manglende pakke fra en skyggelagt pakke. Kjør den med tolken skriptet som feiler bruker, ikke med en annen som tilfeldigvis virker.

Det et prosjektmiljø ikke kan gjøre, er å reparere et frontend som distribusjonen har pakket. Avhengighetene til det programmet ble bygget for tolken pakkebehandleren valgte, og å kjøre det inne i prosjektmiljøet ditt feiler enten eller gir en blanding ingen støtter. Å sprøyte stier inn i det med en miljøvariabel er samme feilen med ekstra trinn: du har endret hva verktøyet laster inn uten å endre hva det er testet mot. Den byttehandelen ser ut som en rettelse nøyaktig så lenge det tar å treffe neste import.

Hvorfor det er en felle å peke systemtolken om

Å endre standardtolken er fristende fordi det ser ut til å rette tracebacken med én kommando. Det bryter også antakelsen hvert pakket Python-verktøy på verten ble bygget på, og feilene dukker opp senere og på urelaterte steder.

Alternativvelgerne ble laget for å bytte mellom likeverdige implementasjoner, ikke for å installere et nyere språk under eldre kompilerte moduler. Kompilerte utvidelser bygges for en bestemt ABI, så en modul som ble importert i går, kan i dag feile på lasting uten at én pakke er fjernet.

Det er også en navnefelle i rådene folk finner. Kommandoen python uten versjon har ikke én universell betydning på tvers av distribusjoner og miljøer, og å behandle den som en fast synonym for en bestemt hovedversjon gir rettelser som bare virker på maskinen der de ble skrevet. Les policyen til systemet foran deg i stedet for den i blogginnlegget.

Adskilte akseptansetester

To tester hører hjemme på slutten, og å bestå én sier ingenting om den andre. Den første er at den støttede klientkommandoen virker med tolken den ble pakket for. Den andre er at den privilegerte tjenesten oppretter en sesjon og tunnelen frakter trafikk.

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

Hold en uavhengig vei inn på maskinen mens du arbeider, særlig hvis VPN-en frakter din eneste administrative tilgang. En endring av en systemtolk er nettopp den typen redigering som kan fjerne den tilgangen halvveis.

Hvis feilen er en manglende modul for et systemverktøy, er rettelsen en pakkeoperasjon gjennom den støttede arbeidsflyten. Hvis feilen er en versjonskonflikt i ditt eget prosjekt, er rettelsen et miljø. Å velge mellom de to er hele avgjørelsen, og den avgjøres av hvilket program som skrev ut tracebacken.