OpenVPN 3 Python-fout: herstel die gereedskap, nie die stelsel se Python nie

’n Traceback verskyn wanneer ’n VPN-beheeropdrag begin, en die eerste instink is om ’n ander Python te installeer of die stelsel se verstek elders te wys. Daardie instink meng twee looptye wat niks met mekaar te doen het nie. Die een behoort aan die bedryfstelsel en sy verpakte gereedskap; die ander behoort aan watter projek jy ook al bou. Om die eerste te verander om die tweede te bevredig, is hoe ’n werkende lessenaar sy pakketbestuurder verloor.

Die vergelyking wat die moeite werd is, is tussen die komponent wat werklik gefaal het en die looptyd wat jy geregtig is om te verander. Hulle is byna nooit dieselfde voorwerp nie.

Twee Python-vrae wat soos een lyk

Die eerste vraag is: watter interpreteerder het die program laat loop wat die traceback gedruk het? Die tweede is: watter interpreteerder moet my projek gebruik? Hulle lyk identies in ’n terminaal omdat albei beantwoord word deur python3 te tik, en hulle het verskillende eienaars, verskillende opgradeerpaaie en verskillende skadegebiede.

’n Stelselgereedskap is gebind aan die interpreteerder waarmee sy distribusie gestuur is, saam met die saamgestelde modules wat teen daardie interpreteerder se ABI gebou is. ’n Projek is gebind aan watter omgewing jy ook al daarvoor skep. Om die stelsel se verstek te verskuif, verander die eerste vir elke gereedskap op die masjien gelyktydig; om ’n omgewing te skep, verander die tweede vir een gids.

Net een van daardie aksies is binne ’n minuut omkeerbaar. Dit is nie die eerste een nie.

Watter komponent het die fout voortgebring

Lees die eerste reël van die traceback en die uitvoerbare lêer wat dit voortgebring het voordat jy enigiets anders lees. Die opdragreël-frontend, die bevoorregte diens en die API-bindings is aparte stukke, en net sommige daarvan is hoegenaamd 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

Die eerste reël van ’n script noem die interpreteerder wat dit sal gebruik, en dit is die interpreteerder waaruit die traceback gekom het. Die pakketnavraag vertel jou wie die lêer besit, wat besluit wie dit mag verander. Die diensstatus beantwoord ’n heeltemal ander vraag: of die bevoorregte agterkant wat werklik sessies vestig, loop.

’n Module-invoerfout, ’n weiering van D-Bus-aktivering en ’n verwerpte geloofsbrief is drie verskillende stadiums. ’n Invoerfout gebeur voordat enige sessie bestaan, so geen hoeveelheid VPN-opstelling sal dit regmaak nie, en ’n werkende diens sal dit ook nie regmaak nie. Om die boodskap in een van daardie drie stadiums te sorteer, is die werklike eerste stap.

Wat ’n projekomgewing kan regmaak en wat nie

’n Projekomgewing los ’n projekprobleem op: die presiese biblioteekweergawes wat een toepassing nodig het, geïsoleer van alles anders. Dit is werklik nuttig, en dit is die regte gereedskap wanneer die falende program ’n script is wat jy besit.

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

Die tweede opdrag wys watter kopie van die bindings ’n gegewe interpreteerder kan sien, wat die vinnigste manier is om ’n ontbrekende pakket van ’n oorskaduwde een te onderskei. Voer dit uit met die interpreteerder wat die falende script gebruik, nie met ’n ander een wat toevallig werk nie.

Wat ’n projekomgewing nie kan doen nie, is om ’n frontend wat deur die distribusie verpak is, te herstel. Daardie program se afhanklikhede is gebou vir die interpreteerder wat die pakketbestuurder gekies het, en om dit binne jou projek se omgewing te laat loop, faal óf lewer ’n mengsel wat niemand ondersteun nie. Om paaie daarin in te spuit met ’n omgewingsveranderlike is dieselfde fout met ekstra stappe: jy het verander wat die gereedskap laai sonder om te verander waarteen dit getoets is. Daardie ruil lyk soos ’n oplossing presies so lank as wat dit neem om die volgende invoer te tref.

Hoekom dit ’n lokval is om die stelsel se interpreteerder te herwys

Om die verstek-interpreteerder te verander is aantreklik omdat dit lyk of dit die traceback in een opdrag regmaak. Dit breek ook die aanname waarop elke verpakte Python-gereedskap op die gasheer gebou is, en die foute verskyn later en op onverbandhoudende plekke.

Meganismes vir alternatief-keuse is ontwerp om tussen gelykwaardige implementerings te wissel, nie om ’n nuwer taal onder ouer saamgestelde modules te installeer nie. Saamgestelde uitbreidings word vir ’n spesifieke ABI gebou, so ’n module wat gister ingevoer is, kan vandag faal om te laai sonder dat enige pakket verwyder is.

Daar is ook ’n naamval-lokval in die advies wat mense vind. Die ongenommerde python-opdrag het nie een universele betekenis oor distribusies en omgewings nie, en om dit as ’n vaste sinoniem vir ’n bepaalde hoofweergawe te behandel, lewer oplossings wat net op die masjien werk waar hulle geskryf is. Lees die beleid van die stelsel voor jou eerder as die een in die blogpos.

Aparte aanvaardingstoetse

Twee toetse hoort aan die einde, en om die een te slaag sê niks oor die ander nie. Die eerste is dat die ondersteunde kliëntopdrag werk met die interpreteerder waarvoor dit verpak is. Die tweede is dat die bevoorregte diens ’n sessie vestig en die tonnel verkeer dra.

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

Hou ’n onafhanklike manier na die masjien terwyl jy werk, veral as die VPN jou enigste administratiewe toegang dra. ’n Verandering aan ’n stelsel-interpreteerder is presies die soort wysiging wat daardie toegang halfpad kan wegneem.

As die fout ’n ontbrekende module vir ’n stelselgereedskap is, is die regstelling ’n pakketbewerking deur die ondersteunde werkvloei. As die fout ’n weergawekonflik in jou eie projek is, is die regstelling ’n omgewing. Om tussen daardie twee te kies is die hele besluit, en dit word bepaal deur watter program die traceback gedruk het.