Python-fout in OpenVPN 3: repareer het gereedschap, niet de systeem-Python

Een traceback verschijnt wanneer een VPN-beheercommando start, en de eerste reflex rent naar het installeren van een andere Python of het systeemstandaard ergens anders heen wijzen. Die reflex mengt twee runtimes die niets met elkaar te maken hebben. De ene hoort bij het besturingssysteem en zijn verpakte gereedschappen; de andere hoort bij welk project u ook bouwt. De eerste veranderen om de tweede te bevredigen is hoe een werkende desktop zijn pakketbeheerder verliest.

De vergelijking die de moeite waard is, is die tussen het onderdeel dat daadwerkelijk faalde en de runtime die u mag veranderen. Ze zijn bijna nooit hetzelfde object.

Twee Python-vragen die er één lijken

De eerste vraag is: welke interpreter voerde het programma uit dat de traceback afdrukte? De tweede is: welke interpreter moet mijn project gebruiken? In een terminal lijken ze identiek, omdat beide worden beantwoord door python3 te typen, en ze hebben verschillende eigenaren, verschillende upgradepaden en verschillende invloedsradii.

Een systeemgereedschap is gebonden aan de interpreter waarmee de distributie het meeleverde, samen met de gecompileerde modules die tegen de ABI van die interpreter zijn gebouwd. Een project is gebonden aan welke omgeving u er ook voor maakt. De systeemstandaard verplaatsen verandert de eerste voor elk gereedschap op de machine tegelijk; een omgeving maken verandert de tweede voor één map.

Slechts één van die acties is binnen een minuut terug te draaien. Dat is niet de eerste.

Welk onderdeel produceerde de fout

Lees de eerste regel van de traceback en het uitvoerbare bestand dat hem produceerde voordat u iets anders leest. De frontend op de opdrachtregel, de bevoorrechte dienst en de API-bindingen zijn afzonderlijke stukken, en slechts enkele ervan zijn helemaal 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

De eerste regel van een script noemt de interpreter die het zal gebruiken, en dat is de interpreter waar de traceback vandaan kwam. De pakketnavraag vertelt u wie het bestand bezit, wat bepaalt wie het mag wijzigen. De dienststatus beantwoordt een heel andere vraag: of de bevoorrechte backend die daadwerkelijk sessies opent, draait.

Een module-importfout, een weigering van D-Bus-activering en een geweigerde referentie zijn drie verschillende fasen. Een importfout gebeurt voordat er een sessie bestaat, dus geen enkele hoeveelheid VPN-configuratie lost hem op, en een werkende dienst lost hem ook niet op. De melding in een van die drie fasen onderbrengen is de echte eerste stap.

Wat een projectomgeving wel en niet kan repareren

Een projectomgeving lost een projectprobleem op: de exacte bibliotheekversies die één toepassing nodig heeft, geïsoleerd van al het andere. Dat is echt nuttig, en het is het juiste gereedschap wanneer het falende programma een script van u is.

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

Het tweede commando laat zien welke kopie van de bindingen een gegeven interpreter kan zien, en dat is de snelste manier om een ontbrekend pakket van een overschaduwd pakket te onderscheiden. Voer het uit met de interpreter die het falende script gebruikt, niet met een andere die toevallig werkt.

Wat een projectomgeving niet kan, is een door de distributie verpakt frontend repareren. De afhankelijkheden van dat programma zijn gebouwd voor de interpreter die de pakketbeheerder koos, en het in de omgeving van uw project draaien mislukt of levert een mengeling op die niemand ondersteunt. Paden erin injecteren met een omgevingsvariabele is dezelfde fout met extra stappen: u hebt veranderd wat het gereedschap laadt zonder te veranderen waartegen het is getest. Die ruil ziet er precies zo lang als een oplossing uit als het duurt om de volgende import te raken.

Waarom de systeeminterpreter omleiden een valstrik is

De standaardinterpreter veranderen is aantrekkelijk omdat het de traceback met één commando lijkt op te lossen. Het breekt ook de aanname waarop elk verpakt Python-gereedschap op de host is gebouwd, en de fouten verschijnen later en op ongerelateerde plaatsen.

Mechanismen voor alternatiefselectie zijn ontworpen om tussen gelijkwaardige implementaties te schakelen, niet om een nieuwere taal onder oudere gecompileerde modules te installeren. Gecompileerde extensies worden voor een specifieke ABI gebouwd, dus een module die gisteren importeerde kan vandaag niet meer laden zonder dat er één pakket is verwijderd.

Er zit ook een naamval in het advies dat mensen vinden. Het commando python zonder versie heeft geen universele betekenis over distributies en omgevingen heen, en het behandelen als een vast synoniem voor een bepaalde hoofdversie levert oplossingen op die alleen werken op de machine waar ze zijn geschreven. Lees het beleid van het systeem voor u, niet dat uit het blogbericht.

Gescheiden acceptatietests

Aan het einde horen twee tests, en slagen voor de ene zegt niets over de andere. De eerste is dat het ondersteunde clientcommando werkt met de interpreter waarvoor het is verpakt. De tweede is dat de bevoorrechte dienst een sessie opzet en de tunnel verkeer draagt.

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

Houd een onafhankelijke weg naar de machine open terwijl u werkt, vooral als de VPN uw enige beheerderstoegang draagt. Een wijziging aan een systeeminterpreter is precies het soort bewerking dat die toegang halverwege kan wegnemen.

Als de fout een ontbrekende module voor een systeemgereedschap is, is de correctie een pakketbewerking via de ondersteunde werkwijze. Als de fout een versieconflict in uw eigen project is, is de correctie een omgeving. Kiezen tussen die twee is de hele beslissing, en die wordt bepaald door welk programma de traceback afdrukte.