OpenVPN-Installation scheitert, weil Gits gpg unter PATH gewinnt

Eine OpenVPN-Installation, die unter Chocolatey mit einem Signatur- oder Schlüsselfehler abbricht, ist meist kein Downloadproblem. Das Paket führt einen Prüfschritt aus, der gpg aufruft, und Windows löst diesen bloßen Namen über PATH auf. Wurde Git for Windows zuerst installiert, steht sein mitgeliefertes gpg.exe vor dem GnuPG-Build, das OpenVPN erwartet, und das falsche Programm beantwortet den Aufruf. Der Fehler, den Sie sehen, ist das, worüber sich das andere Programm beschwert hat, deshalb nennt er nie die eigentliche Ursache.

Die PATH-Reihenfolge entscheidet, welches gpg läuft

Windows hat keine zentrale Registrierung ausführbarer Namen. Wenn ein Prozess gpg ohne vollständigen Pfad anfordert, durchläuft der Loader die Einträge in PATH der Reihe nach und führt die erste Übereinstimmung aus. Git for Windows liefert einen minimalen GnuPG-Build in seinem Verzeichnis usr/bin mit, damit signierte Commits funktionieren, und sein Installer platziert dieses Verzeichnis normalerweise nahe am Anfang des PATH des Benutzers.

GnuPG installiert sich in ein eigenes Verzeichnis, üblicherweise C:\Program Files (x86)\GNU\GnuPG\pub, und dieser Eintrag steht möglicherweise weiter hinten in der Liste oder fehlt ganz im PATH des Benutzers. Die beiden Programme teilen einen Namen und einen Großteil einer Kommandozeilenoberfläche, aber nicht ihren Zustand: Der Git-Build sucht einen Schlüsselbund woanders, ist vielleicht eine andere Version und akzeptiert möglicherweise nicht die Optionen, die der Installer übergibt. Diese Diskrepanz äußert sich als Signatur- oder Schlüsselfehler, was ein wahrheitsgemäßer Bericht darüber ist, was die falsche Binärdatei gesehen hat. Nichts in der Meldung deutet auf den Loader hin, denn der Loader tat genau, was ihm gesagt wurde.

Warum die Shell, aus der Sie starten, das Ergebnis bestimmt

Die Vererbungsregel ist der Teil, den es sich zu verinnerlichen lohnt. Ein Kindprozess erhält die Umgebung der Shell, die ihn gestartet hat, also zählt die Reihenfolge im Moment des Chocolatey-Starts, nicht die Reihenfolge nach Ihrer Korrektur.

Deshalb ändert das Bearbeiten von PATH in einem Einstellungsfenster und das erneute Ausführen der Installation im selben Terminal oft nichts: Das Terminal behielt die alte Umgebung. Starten Sie nach jeder Änderung eine neue Shell und bestätigen Sie mit where.exe gpg in dieser neuen Shell, bevor Sie es erneut versuchen. Das ist auch der Grund, warum ein Eintrag auf Maschinenebene eine Änderung auf Benutzerebene schlagen kann, da einige Installer dem PATH der Maschine voranstellen und Maschineneinträge vor Benutzereinträgen ausgewertet werden. Wenn beide Ebenen einen GnuPG-Pfad enthalten, entscheiden Sie, welchen Sie tatsächlich pflegen.

Korrektur eins: Ordnen Sie die Einträge um

Die genaue Korrektur besteht darin, das gewünschte GnuPG-Verzeichnis gewinnen zu lassen. Öffnen Sie die Umgebungsvariablen des Benutzers, bearbeiten Sie Path und verschieben Sie das GnuPG-Verzeichnis pub über die Git-Einträge. Öffnen Sie dann ein neues PowerShell-Fenster, denn das laufende hält noch die alte Liste.

Die Alternative ist eine temporäre saubere Umgebung für die Installation: Entfernen Sie die Git-Einträge, öffnen Sie eine neue Shell, führen Sie choco install openvpn aus und stellen Sie sie dann wieder her.

Beide Ansätze funktionieren aus demselben Grund, und der zweite ist nur sicher, wenn Sie die Einträge tatsächlich wiederherstellen. Das Entfernen von Gits usr/bin aus PATH bricht signierte Commits dauerhaft, und das nächste Werkzeug, das ein funktionierendes gpg erwartet, scheitert mit einer eigenen Meldung, die nichts mit OpenVPN zu tun hat. Wenn Sie den temporären Weg wählen, bewahren Sie den ursprünglichen Wert von Path im Ticket auf, damit die Wiederherstellung ein Einfügen und kein Nachbau ist. Das Ordnen der Einträge ist die dauerhafte Korrektur; das Löschen ist ein Workaround mit Ablaufdatum.

Prüfen, dann zurückstellen

Prüfen Sie vorher und nachher im selben Benutzerkontext, den Chocolatey verwendet. where.exe gpg listet jede Übereinstimmung in Auflösungsreihenfolge auf, die erste Zeile ist also die, die ausgeführt wird; Get-Command gpg -All liefert in PowerShell dieselbe Antwort mit mehr Details. Anschließend bestätigt gpg --version, welcher Build geantwortet hat.

Wenn where.exe die Git-Kopie immer noch zuerst auflistet, hat die Umordnung diese Sitzung nicht erreicht, und kein Neuinstallieren hilft. Prüfen Sie sowohl den PATH der Maschine als auch den des Benutzers mit [Environment]::GetEnvironmentVariable('Path','Machine') und demselben Aufruf mit 'User', denn die effektive Liste wird aus beiden zusammengesetzt. Prüfen Sie nach einer erfolgreichen Installation erneut mit openvpn --version und starten Sie den Dienst oder die GUI einmal, da ein Paket sauber installieren und dennoch einen Dienst hinterlassen kann, der nicht startet.

Wenn ein korrekt geordnetes PATH weiterhin fehlschlägt, ist die verbleibende Variable die Paketversion. Ein festgelegtes Chocolatey-Paket erwartet möglicherweise einen bestimmten GnuPG-Build oder Installationspfad, den Ihre Maschine nicht hat.

Lesen Sie das eigene Protokoll des Pakets, bevor Sie etwas anderes ändern. C:\ProgramData\chocolatey\logs\chocolatey.log zeichnet die fehlgeschlagene Befehlszeile und das Verzeichnis auf, aus dem sie ausgeführt wurde, was Ihnen sagt, ob der fehlschlagende Aufruf eine Signaturprüfung, eine Extraktion oder ein Post-Install-Skript war. Diese Unterscheidung entscheidet, ob Sie überhaupt noch gpg debuggen.

Die Gewohnheit, die eine Wiederholung verhindert, besteht darin, PATH als gemeinsamen Zustand mit dokumentierter Reihenfolge zu behandeln und nicht als Tasche voller Verzeichnisse. Wenn Sie ein Werkzeug installieren, das einen gängigen Binärnamen mitbringt, prüfen Sie, was es in der nächsten Shell, die Sie öffnen, verdeckt. Schreiben Sie dann die Reihenfolge auf, auf die Sie sich festgelegt haben, denn der nächste Installer wird etwas anhängen, und die nächste Person wird sich fragen, warum eine Signaturprüfung auf einer Maschine fehlschlägt, auf der sich nichts geändert hat. Ein einziges where.exe vor der Installation erspart die ganze Schleife.