Python-Fehler in OpenVPN 3: Reparieren Sie das Werkzeug, nicht das System-Python
Ein Traceback nennt den Interpreter, der ein Frontend gestartet hat, nicht den Dienst, dem der Tunnel gehört. Vergleichen Sie beides, bevor Sie systemweit etwas umbiegen.
Ein Traceback erscheint, wenn ein VPN-Verwaltungsbefehl startet, und der erste Impuls ist, ein anderes Python zu installieren oder den Systemstandard woandershin zu zeigen. Dieser Impuls vermischt zwei Laufzeitumgebungen, die nichts miteinander zu tun haben. Die eine gehört zum Betriebssystem und seinen paketierten Werkzeugen; die andere gehört zu welchem Projekt auch immer Sie gerade bauen. Das erste zu ändern, um das zweite zu befriedigen, ist der Weg, auf dem ein funktionierender Rechner seine Paketverwaltung verliert.
Der Vergleich, der sich lohnt, ist der zwischen der Komponente, die tatsächlich versagt hat, und der Laufzeitumgebung, die Sie ändern dürfen. Sie sind fast nie dasselbe Objekt.
Zwei Python-Fragen, die wie eine aussehen
Die erste Frage lautet: Welcher Interpreter hat das Programm ausgeführt, das den Traceback ausgegeben hat? Die zweite lautet: Welchen Interpreter sollte mein Projekt verwenden? Im Terminal sehen sie identisch aus, weil beide durch Eingabe von python3 beantwortet werden, und sie haben verschiedene Eigentümer, verschiedene Upgrade-Pfade und verschiedene Wirkungsradien.
Ein Systemwerkzeug ist an den Interpreter gebunden, mit dem seine Distribution ausgeliefert wurde, zusammen mit den kompilierten Modulen, die gegen die ABI dieses Interpreters gebaut wurden. Ein Projekt ist an die Umgebung gebunden, die Sie dafür anlegen. Den Systemstandard zu verschieben ändert das erste für jedes Werkzeug auf dem Rechner auf einmal; eine Umgebung anzulegen ändert das zweite für ein Verzeichnis.
Nur eine dieser Aktionen ist in einer Minute umkehrbar. Es ist nicht die erste.
Welche Komponente den Fehler erzeugt hat
Lesen Sie die erste Zeile des Tracebacks und die ausführbare Datei, die ihn erzeugt hat, bevor Sie irgendetwas anderes lesen. Das Kommandozeilen-Frontend, der privilegierte Dienst und die API-Bindings sind getrennte Teile, und nur einige davon sind überhaupt 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 erste Zeile eines Skripts nennt den Interpreter, den es verwenden wird, und aus diesem Interpreter stammt der Traceback. Die Paketabfrage sagt Ihnen, wem die Datei gehört, was entscheidet, wer sie ändern darf. Der Dienststatus beantwortet eine ganz andere Frage: ob das privilegierte Backend läuft, das tatsächlich Sitzungen aufbaut.
Ein Modul-Importfehler, eine verweigerte D-Bus-Aktivierung und ein abgelehnter Anmeldenachweis sind drei verschiedene Stufen. Ein Importfehler tritt auf, bevor irgendeine Sitzung existiert, also behebt ihn keine VPN-Konfiguration, und ein laufender Dienst behebt ihn ebenso wenig. Die Meldung einer dieser drei Stufen zuzuordnen ist der eigentliche erste Schritt.
Was eine Projektumgebung beheben kann und was nicht
Eine Projektumgebung löst ein Projektproblem: die genauen Bibliotheksversionen, die eine Anwendung braucht, isoliert von allem anderen. Das ist wirklich nützlich, und es ist das richtige Werkzeug, wenn das fehlerhafte Programm ein Skript ist, das Ihnen gehört.
uv run --python 3.11 app.py
python3 -c 'import openvpn3; print(openvpn3.__file__)'
Der zweite Befehl zeigt, welche Kopie der Bindings ein gegebener Interpreter sieht, was der schnellste Weg ist, ein fehlendes Paket von einem verdeckten zu unterscheiden. Führen Sie ihn mit dem Interpreter aus, den das fehlerhafte Skript verwendet, nicht mit einem anderen, der zufällig funktioniert.
Was eine Projektumgebung nicht kann, ist ein von der Distribution paketiertes Frontend zu reparieren. Die Abhängigkeiten dieses Programms wurden für den Interpreter gebaut, den die Paketverwaltung gewählt hat, und es in der Umgebung Ihres Projekts auszuführen schlägt entweder fehl oder erzeugt eine Mischung, die niemand unterstützt. Pfade per Umgebungsvariable hineinzuschmuggeln ist derselbe Fehler mit zusätzlichen Schritten: Sie haben geändert, was das Werkzeug lädt, ohne zu ändern, wogegen es getestet wurde. Dieser Tausch sieht genau so lange wie eine Reparatur aus, wie es dauert, bis der nächste Import auftrifft.
Warum das Umbiegen des System-Interpreters eine Falle ist
Den Standard-Interpreter zu ändern ist attraktiv, weil es den Traceback mit einem Befehl zu beheben scheint. Es bricht auch die Annahme, auf der jedes paketierte Python-Werkzeug auf dem Host gebaut wurde, und die Ausfälle zeigen sich später und an nicht zusammenhängenden Stellen.
Mechanismen zur Alternativenauswahl wurden entworfen, um zwischen gleichwertigen Implementierungen zu wechseln, nicht um eine neuere Sprache unter älteren kompilierten Modulen zu installieren. Kompilierte Erweiterungen werden für eine bestimmte ABI gebaut, also kann ein Modul, das gestern importiert wurde, heute nicht mehr laden, ohne dass ein einziges Paket entfernt wurde.
Es gibt auch eine Namensfalle in dem Rat, den Leute finden. Der unversionierte Befehl python hat keine universelle Bedeutung über Distributionen und Umgebungen hinweg, und ihn als festes Synonym für eine bestimmte Hauptversion zu behandeln erzeugt Reparaturen, die nur auf der Maschine funktionieren, auf der sie geschrieben wurden. Lesen Sie die Richtlinie des Systems vor Ihnen statt der aus dem Blogbeitrag.
Getrennte Abnahmetests
Am Ende gehören zwei Tests hin, und das Bestehen des einen sagt nichts über den anderen. Der erste ist, dass der unterstützte Client-Befehl mit dem Interpreter funktioniert, für den er paketiert wurde. Der zweite ist, dass der privilegierte Dienst eine Sitzung aufbaut und der Tunnel Datenverkehr überträgt.
openvpn3 sessions-list
openvpn3-service-client --help 2>/dev/null | head -n 3
ip -4 addr show tun0
Halten Sie sich einen unabhängigen Weg auf den Rechner offen, während Sie arbeiten, besonders wenn das VPN Ihren einzigen administrativen Zugang trägt. Eine Änderung am System-Interpreter ist genau die Art von Eingriff, die diesen Zugang auf halbem Weg entfernen kann.
Wenn der Fehler ein fehlendes Modul für ein Systemwerkzeug ist, ist die Korrektur eine Paketoperation über den unterstützten Ablauf. Wenn der Fehler ein Versionskonflikt in Ihrem eigenen Projekt ist, ist die Korrektur eine Umgebung. Die Wahl zwischen beidem ist die ganze Entscheidung, und sie wird davon entschieden, welches Programm den Traceback ausgegeben hat.