Error de Python en OpenVPN 3: arregle la herramienta, no el Python del sistema

Aparece un traceback cuando se inicia un comando de gestión de VPN, y el primer impulso es instalar otro Python o apuntar el valor predeterminado del sistema a otro sitio. Ese impulso mezcla dos entornos de ejecución que no tienen nada que ver entre sí. Uno pertenece al sistema operativo y a sus herramientas empaquetadas; el otro pertenece al proyecto que esté construyendo. Cambiar el primero para satisfacer al segundo es como un escritorio que funciona pierde su gestor de paquetes.

La comparación que merece la pena es entre el componente que realmente falló y el entorno de ejecución que tiene derecho a cambiar. Casi nunca son el mismo objeto.

Dos preguntas sobre Python que parecen una

La primera pregunta es: ¿qué intérprete ejecutó el programa que imprimió el traceback? La segunda es: ¿qué intérprete debería usar mi proyecto? Parecen idénticas en una terminal porque a ambas se responde escribiendo python3, y tienen propietarios distintos, rutas de actualización distintas y radios de impacto distintos.

Una herramienta del sistema está ligada al intérprete con el que se distribuyó su distribución, junto con los módulos compilados construidos contra la ABI de ese intérprete. Un proyecto está ligado al entorno que cree para él. Mover el valor predeterminado del sistema cambia el primero para todas las herramientas de la máquina a la vez; crear un entorno cambia el segundo para un directorio.

Solo una de esas acciones es reversible en un minuto. No es la primera.

Qué componente produjo el error

Lea la primera línea del traceback y el ejecutable que lo produjo antes de leer cualquier otra cosa. El frontend de línea de comandos, el servicio privilegiado y los enlaces de la API son piezas separadas, y solo algunas de ellas son 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ínea de un script nombra el intérprete que usará, y ese es el intérprete del que vino el traceback. La consulta del paquete le dice quién posee el archivo, lo que decide quién puede cambiarlo. El estado del servicio responde una pregunta completamente distinta: si se está ejecutando el backend privilegiado que realmente establece sesiones.

Un error de importación de módulo, un rechazo de activación de D-Bus y una credencial rechazada son tres etapas distintas. Un error de importación ocurre antes de que exista sesión alguna, así que ninguna configuración de VPN lo arreglará, y un servicio que funcione tampoco lo arreglará. Clasificar el mensaje en una de esas tres etapas es el primer paso real.

Qué puede arreglar un entorno de proyecto y qué no

Un entorno de proyecto resuelve un problema de proyecto: las versiones exactas de las bibliotecas que necesita una aplicación, aisladas de todo lo demás. Eso es genuinamente útil, y es la herramienta correcta cuando el programa que falla es un script suyo.

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

El segundo comando muestra qué copia de los enlaces puede ver un intérprete dado, que es la forma más rápida de distinguir un paquete ausente de uno ensombrecido. Ejecútelo con el intérprete que usa el script que falla, no con otro que funcione por casualidad.

Lo que un entorno de proyecto no puede hacer es reparar un frontend empaquetado por la distribución. Las dependencias de ese programa se construyeron para el intérprete que eligió el gestor de paquetes, y ejecutarlo dentro del entorno de su proyecto o bien falla o bien produce una mezcla que nadie admite. Inyectarle rutas con una variable de entorno es el mismo error con pasos extra: ha cambiado lo que la herramienta carga sin cambiar aquello contra lo que se probó. Ese intercambio parece una solución exactamente hasta que llega la siguiente importación.

Por qué redirigir el intérprete del sistema es una trampa

Cambiar el intérprete predeterminado es atractivo porque parece arreglar el traceback con un solo comando. También rompe la suposición sobre la que se construyó cada herramienta de Python empaquetada del equipo, y los fallos aparecen más tarde y en lugares sin relación.

Los mecanismos de selección de alternativas se diseñaron para cambiar entre implementaciones equivalentes, no para instalar un lenguaje más nuevo bajo módulos compilados más antiguos. Las extensiones compiladas se construyen para una ABI concreta, así que un módulo que se importaba ayer puede no cargarse hoy sin que se haya eliminado un solo paquete.

También hay una trampa de nombre en el consejo que encuentra la gente. El comando python sin versión no tiene un significado universal entre distribuciones y entornos, y tratarlo como sinónimo fijo de una versión principal concreta produce correcciones que solo funcionan en la máquina donde se escribieron. Lea la política del sistema que tiene delante, no la del artículo del blog.

Pruebas de aceptación separadas

Al final deben ir dos pruebas, y pasar una no dice nada de la otra. La primera es que el comando de cliente admitido funciona con el intérprete para el que se empaquetó. La segunda es que el servicio privilegiado establece una sesión y el túnel transporta tráfico.

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

Mantenga una vía independiente hacia la máquina mientras trabaja, sobre todo si la VPN lleva su único acceso administrativo. Un cambio en el intérprete del sistema es justo el tipo de edición que puede quitar ese acceso a mitad de camino.

Si el fallo es un módulo ausente para una herramienta del sistema, la corrección es una operación de paquete a través del flujo de trabajo admitido. Si el fallo es un conflicto de versiones en su propio proyecto, la corrección es un entorno. Elegir entre esos dos es toda la decisión, y la decide qué programa imprimió el traceback.