Erreur Python dans OpenVPN 3 : corrigez l’outil, pas le Python du système

Une trace apparaît au démarrage d’une commande de gestion de VPN, et le premier réflexe est d’installer un autre Python ou de pointer la valeur par défaut du système ailleurs. Ce réflexe mélange deux environnements d’exécution qui n’ont rien à voir l’un avec l’autre. L’un appartient au système d’exploitation et à ses outils empaquetés ; l’autre appartient à n’importe quel projet que vous construisez. Changer le premier pour satisfaire le second, c’est ainsi qu’un poste qui fonctionne perd son gestionnaire de paquets.

La comparaison qui vaut la peine est entre le composant qui a réellement échoué et l’environnement d’exécution que vous avez le droit de modifier. Ce ne sont presque jamais le même objet.

Deux questions sur Python qui n’en font qu’une en apparence

La première question est : quel interpréteur a lancé le programme qui a imprimé la trace ? La seconde est : quel interpréteur mon projet devrait-il utiliser ? Elles semblent identiques dans un terminal parce qu’on y répond toutes deux en tapant python3, et elles ont des propriétaires différents, des chemins de mise à jour différents et des rayons d’action différents.

Un outil système est lié à l’interpréteur avec lequel sa distribution a été livrée, ainsi qu’aux modules compilés construits contre l’ABI de cet interpréteur. Un projet est lié à l’environnement que vous créez pour lui. Déplacer la valeur par défaut du système modifie le premier pour tous les outils de la machine d’un coup ; créer un environnement modifie le second pour un répertoire.

Une seule de ces actions est réversible en une minute. Ce n’est pas la première.

Quel composant a produit l’erreur

Lisez la première ligne de la trace et l’exécutable qui l’a produite avant de lire quoi que ce soit d’autre. Le frontal en ligne de commande, le service privilégié et les liaisons de l’API sont des pièces distinctes, et seules certaines d’entre elles sont du 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 première ligne d’un script nomme l’interpréteur qu’il utilisera, et c’est de cet interpréteur que vient la trace. La requête de paquet vous dit à qui appartient le fichier, ce qui décide qui a le droit de le modifier. L’état du service répond à une question entièrement différente : si le backend privilégié qui établit réellement les sessions tourne.

Une erreur d’import de module, un refus d’activation D-Bus et un identifiant rejeté sont trois étapes différentes. Une erreur d’import survient avant qu’aucune session n’existe, donc aucune configuration VPN ne la corrigera, et un service qui fonctionne ne la corrigera pas non plus. Classer le message dans l’une de ces trois étapes est le véritable premier pas.

Ce qu’un environnement de projet peut corriger et ce qu’il ne peut pas

Un environnement de projet résout un problème de projet : les versions exactes des bibliothèques dont une application a besoin, isolées de tout le reste. C’est réellement utile, et c’est le bon outil lorsque le programme qui échoue est un script qui vous appartient.

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

La seconde commande montre quelle copie des liaisons un interpréteur donné voit, ce qui est le moyen le plus rapide de distinguer un paquet manquant d’un paquet masqué. Lancez-la avec l’interpréteur qu’utilise le script qui échoue, pas avec un autre qui fonctionne par hasard.

Ce qu’un environnement de projet ne peut pas faire, c’est réparer un frontal empaqueté par la distribution. Les dépendances de ce programme ont été construites pour l’interpréteur choisi par le gestionnaire de paquets, et l’exécuter dans l’environnement de votre projet échoue ou produit un mélange que personne ne prend en charge. Injecter des chemins dedans avec une variable d’environnement est la même erreur avec des étapes en plus : vous avez changé ce que l’outil charge sans changer ce contre quoi il a été testé. Cet échange ressemble à un correctif exactement jusqu’au moment où la prochaine importation arrive.

Pourquoi rediriger l’interpréteur du système est un piège

Changer l’interpréteur par défaut est tentant parce que cela semble corriger la trace en une seule commande. Cela casse aussi l’hypothèse sur laquelle chaque outil Python empaqueté de l’hôte a été construit, et les pannes apparaissent plus tard et à des endroits sans rapport.

Les mécanismes de sélection d’alternative ont été conçus pour basculer entre des implémentations équivalentes, pas pour installer un langage plus récent sous des modules compilés plus anciens. Les extensions compilées sont construites pour une ABI précise, donc un module importé hier peut ne plus se charger aujourd’hui sans qu’un seul paquet ait été retiré.

Il y a aussi un piège de nommage dans le conseil que les gens trouvent. La commande python sans version n’a pas un sens universel d’une distribution et d’un environnement à l’autre, et la traiter comme un synonyme figé d’une version majeure particulière produit des correctifs qui ne fonctionnent que sur la machine où ils ont été écrits. Lisez la politique du système qui est devant vous plutôt que celle du billet de blog.

Des tests d’acceptation séparés

Deux tests doivent venir à la fin, et réussir l’un ne dit rien de l’autre. Le premier est que la commande client prise en charge fonctionne avec l’interpréteur pour lequel elle a été empaquetée. Le second est que le service privilégié établit une session et que le tunnel transporte le trafic.

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

Gardez un chemin indépendant vers la machine pendant que vous travaillez, surtout si le VPN porte votre seul accès administratif. Une modification de l’interpréteur système est exactement le genre d’édition qui peut retirer cet accès en cours de route.

Si la panne est un module manquant pour un outil système, la correction est une opération de paquet via le flux de travail pris en charge. Si la panne est un conflit de versions dans votre propre projet, la correction est un environnement. Choisir entre ces deux-là, c’est toute la décision, et elle se décide selon le programme qui a imprimé la trace.