Python-fel i OpenVPN 3: laga verktyget, inte systemets Python

En traceback dyker upp när ett VPN-administrationskommando startar, och den första instinkten springer mot att installera en annan Python eller peka systemets standard någon annanstans. Den instinkten blandar två körtider som inte har något med varandra att göra. Den ena tillhör operativsystemet och dess paketerade verktyg; den andra tillhör vilket projekt du än bygger. Att ändra den första för att tillfredsställa den andra är hur ett fungerande skrivbord förlorar sin pakethanterare.

Jämförelsen som är värd att göra är mellan komponenten som faktiskt misslyckades och körtiden du har rätt att ändra. De är nästan aldrig samma objekt.

Två Python-frågor som ser ut som en

Den första frågan är: vilken tolk körde programmet som skrev ut tracebacken? Den andra är: vilken tolk ska mitt projekt använda? I en terminal ser de identiska ut, eftersom båda besvaras genom att skriva python3, och de har olika ägare, olika uppgraderingsvägar och olika sprängradie.

Ett systemverktyg är bundet till den tolk distributionen levererade det med, tillsammans med de kompilerade moduler som byggts mot den tolkens ABI. Ett projekt är bundet till vilken miljö du än skapar för det. Att flytta systemets standard ändrar den första för varje verktyg på maskinen på en gång; att skapa en miljö ändrar den andra för en enda katalog.

Bara en av dessa åtgärder går att ångra på en minut. Det är inte den första.

Vilken komponent producerade felet

Läs den första raden i tracebacken och den körbara filen som producerade den innan du läser något annat. Frontendet på kommandoraden, den privilegierade tjänsten och API-bindningarna är separata delar, och bara några av dem är Python överhuvudtaget.

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örsta raden i ett skript namnger tolken det ska använda, och det är tolken tracebacken kom från. Paketfrågan berättar vem som äger filen, vilket avgör vem som får ändra den. Tjänstens status svarar på en helt annan fråga: om den privilegierade backend som faktiskt upprättar sessioner körs.

Ett modulimportfel, ett avslag på D-Bus-aktivering och en avvisad autentisering är tre olika stadier. Ett importfel inträffar innan någon session finns, så ingen mängd VPN-konfiguration rättar det, och en fungerande tjänst rättar det inte heller. Att sortera in meddelandet i ett av dessa tre stadier är det egentliga första steget.

Vad en projektmiljö kan och inte kan laga

En projektmiljö löser ett projektproblem: de exakta biblioteksversioner en applikation behöver, isolerade från allt annat. Det är verkligen användbart, och det är rätt verktyg när programmet som misslyckas är ett skript du äger.

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

Det andra kommandot visar vilken kopia av bindningarna en given tolk kan se, och det är det snabbaste sättet att skilja ett saknat paket från ett skuggat. Kör det med tolken som det misslyckade skriptet använder, inte med en annan som råkar fungera.

Vad en projektmiljö inte kan göra är att reparera ett frontend som distributionen paketerat. Det programmets beroenden byggdes för tolken som pakethanteraren valde, och att köra det inuti projektets miljö misslyckas antingen eller ger en blandning som ingen stöder. Att injicera sökvägar i det med en miljövariabel är samma misstag med extra steg: du har ändrat vad verktyget laddar utan att ändra vad det testats mot. Den byteshandeln ser ut som en rättelse exakt så länge det tar att nå nästa import.

Varför det är en fälla att peka om systemtolken

Att ändra standardtolken är lockande eftersom det ser ut att rätta tracebacken med ett enda kommando. Det bryter också det antagande som varje paketerat Python-verktyg på värden byggdes på, och felen dyker upp senare och på orelaterade ställen.

Mekanismerna för alternativval skapades för att växla mellan likvärdiga implementationer, inte för att installera ett nyare språk under äldre kompilerade moduler. Kompilerade tillägg byggs för ett specifikt ABI, så en modul som importerades i går kan i dag misslyckas med att laddas utan att ett enda paket tagits bort.

Det finns också en namnfälla i råden folk hittar. Kommandot python utan version har inte en universell betydelse mellan distributioner och miljöer, och att behandla det som en fast synonym för en viss huvudversion ger rättelser som bara fungerar på maskinen där de skrevs. Läs policyn för systemet framför dig i stället för den i blogginlägget.

Separat acceptanstester

I slutet hör två tester hemma, och att klara det ena säger ingenting om det andra. Det första är att det stödda klientkommandot fungerar med tolken det paketerades för. Det andra är att den privilegierade tjänsten upprättar en session och att tunneln bär trafik.

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

Behåll en oberoende väg in på maskinen medan du arbetar, särskilt om VPN:en bär din enda administrativa åtkomst. En ändring av en systemtolk är precis den sorts redigering som kan ta bort den åtkomsten halvvägs.

Om felet är en saknad modul för ett systemverktyg är rättelsen en paketoperation genom det stödda arbetsflödet. Om felet är en versionskonflikt i ditt eget projekt är rättelsen en miljö. Att välja mellan de två är hela beslutet, och det avgörs av vilket program som skrev ut tracebacken.