Error de Python a l’OpenVPN 3: arregleu l’eina, no el Python del sistema

Apareix un traceback quan s’inicia una ordre de gestió de VPN, i el primer impuls és instal·lar un Python diferent o apuntar el valor per defecte del sistema a un altre lloc. Aquest impuls barreja dos entorns d’execució que no tenen res a veure entre si. Un pertany al sistema operatiu i a les seves eines empaquetades; l’altre pertany a qualsevol projecte que estigueu construint. Canviar el primer per satisfer el segon és com un escriptori que funciona perd el seu gestor de paquets.

La comparació que val la pena fer és entre el component que realment va fallar i l’entorn d’execució que teniu dret a canviar. Gairebé mai no són el mateix objecte.

Dues preguntes sobre Python que semblen una

La primera pregunta és: quin intèrpret va executar el programa que va imprimir el traceback? La segona és: quin intèrpret hauria d’utilitzar el meu projecte? Semblen idèntiques en un terminal perquè totes dues es responen escrivint python3, i tenen propietaris diferents, camins d’actualització diferents i radis d’impacte diferents.

Una eina del sistema està lligada a l’intèrpret amb què es va distribuir la seva distribució, juntament amb els mòduls compilats construïts per a l’ABI d’aquell intèrpret. Un projecte està lligat a l’entorn que li creeu. Moure el valor per defecte del sistema canvia el primer per a totes les eines de la màquina alhora; crear un entorn canvia el segon per a un directori.

Només una d’aquestes accions és reversible en un minut. I no és la primera.

Quin component va produir l’error

Llegiu la primera línia del traceback i l’executable que el va produir abans de llegir res més. El frontal de línia d’ordres, el servei privilegiat i els enllaços de l’API són peces separades, i només algunes són 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

La primera línia d’un script nomena l’intèrpret que utilitzarà, i és l’intèrpret d’on va sortir el traceback. La consulta del paquet us diu qui posseeix el fitxer, cosa que decideix qui té permís per canviar-lo. L’estat del servei respon una pregunta completament diferent: si s’executa el backend privilegiat que realment estableix sessions.

Un error d’importació de mòdul, un refús d’activació de D-Bus i una credencial rebutjada són tres etapes diferents. L’error d’importació passa abans que existeixi cap sessió, així que cap configuració de VPN el corregirà, i un servei que funcioni tampoc no el corregirà. Classificar el missatge en una d’aquestes tres etapes és el primer pas real.

Què pot corregir un entorn de projecte i què no

Un entorn de projecte resol un problema de projecte: les versions exactes de les biblioteques que necessita una aplicació, aïllades de tota la resta. Això és realment útil, i és l’eina adequada quan el programa que falla és un script vostre.

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

La segona ordre mostra quina còpia dels enllaços pot veure un intèrpret determinat, que és la manera més ràpida de distingir un paquet que falta d’un paquet ombrejat. Executeu-la amb l’intèrpret que utilitza l’script que falla, no amb un altre que funcioni per casualitat.

El que un entorn de projecte no pot fer és reparar un frontal empaquetat per la distribució. Les dependències d’aquest programa es van construir per a l’intèrpret que va triar el gestor de paquets, i executar-lo dins de l’entorn del vostre projecte o bé falla o bé produeix una barreja que ningú no dona suport. Injectar-hi camins amb una variable d’entorn és el mateix error amb passos extra: heu canviat què carrega l’eina sense canviar contra què es va provar. Aquest intercanvi sembla una solució exactament fins que arriba la propera importació.

Per què redirigir l’intèrpret del sistema és una trampa

Canviar l’intèrpret per defecte és atractiu perquè sembla que corregeix el traceback amb una sola ordre. També trenca la suposició sobre la qual es va construir cada eina Python empaquetada de l’amfitrió, i les fallades apareixen més tard i en llocs sense relació.

Els mecanismes de selecció d’alternatives es van dissenyar per canviar entre implementacions equivalents, no per instal·lar un llenguatge més nou sota mòduls compilats més antics. Les extensions compilades es construeixen per a una ABI concreta, així que un mòdul que s’importava ahir pot no carregar-se avui sense que s’hagi eliminat cap paquet.

També hi ha una trampa de nomenclatura en el consell que troba la gent. L’ordre python sense versió no té un significat universal entre distribucions i entorns, i tractar-la com un sinònim fix d’una versió principal concreta produeix correccions que només funcionen a la màquina on es van escriure. Llegiu la política del sistema que teniu davant, no la de l’article del blog.

Proves d’acceptació separades

Al final hi han d’haver dues proves, i passar-ne una no diu res de l’altra. La primera és que l’ordre de client compatible funciona amb l’intèrpret per al qual es va empaquetar. La segona és que el servei privilegiat estableix una sessió i el túnel transporta trànsit.

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

Manteniu una via independent cap a la màquina mentre treballeu, sobretot si la VPN porta el vostre únic accés administratiu. Un canvi a l’intèrpret del sistema és exactament el tipus d’edició que pot eliminar aquest accés a mig camí.

Si la fallada és un mòdul que falta per a una eina del sistema, la correcció és una operació de paquet a través del flux de treball compatible. Si la fallada és un conflicte de versions al vostre projecte, la correcció és un entorn. Triar entre aquests dos és tota la decisió, i la decideix quin programa va imprimir el traceback.