OpenVPN-installatie mislukt omdat de gpg van Git wint op PATH

Een OpenVPN-installatie die onder Chocolatey sterft met een handtekening- of sleutelfout is meestal geen downloadprobleem. Het pakket voert een verificatiestap uit die gpg aanroept, en Windows lost die kale naam op via PATH. Als Git for Windows eerst is geïnstalleerd, staat de meegeleverde gpg.exe vóór de GnuPG-build die OpenVPN verwacht, en het verkeerde programma beantwoordt de oproep. De fout die u ziet is wat dat andere programma besloot te melden, en daarom noemt die nooit de echte oorzaak.

De PATH-volgorde bepaalt welke gpg draait

Windows heeft geen centraal register van uitvoerbare namen. Wanneer een proces gpg zonder volledig pad aanvraagt, loopt de loader de vermeldingen in PATH op volgorde af en voert de eerste overeenkomst uit. Git for Windows levert een minimale GnuPG-build in zijn map usr/bin zodat ondertekende commits werken, en de installer plaatst die map meestal vlak bij het begin van de PATH van de gebruiker.

GnuPG installeert in zijn eigen map, meestal C:\Program Files (x86)\GNU\GnuPG\pub, en die vermelding staat misschien later in de lijst of ontbreekt helemaal in de PATH van de gebruiker. De twee programma's delen een naam en een groot deel van een opdrachtregelinterface, maar niet hun toestand: de Git-build zoekt een sleutelbos elders, is misschien een andere versie en accepteert mogelijk niet de opties die de installer doorgeeft. Die mismatch komt naar voren als een handtekening- of sleutelfout, wat een waarheidsgetrouw verslag is van wat de verkeerde binary zag. Niets in de melding wijst naar de loader, omdat de loader precies deed wat hem was gezegd.

Waarom de shell waarin u begint het resultaat bepaalt

De overervingsregel is het deel dat het waard is om te internaliseren. Een kindproces krijgt de omgeving van de shell die het startte, dus de volgorde die telt is die op het moment dat Chocolatey begint, niet die na uw correctie.

Daarom verandert het bewerken van PATH in een instellingenvenster en het opnieuw uitvoeren van de installatie in dezelfde terminal vaak niets: de terminal hield de oude omgeving. Start na elke wijziging een nieuwe shell en bevestig met where.exe gpg in die nieuwe shell voordat u het opnieuw probeert. Dat is ook de reden waarom een vermelding op machineniveau een wijziging op gebruikersniveau kan verslaan, omdat sommige installers vooraan in de PATH van de machine toevoegen en machinevermeldingen vóór gebruikersvermeldingen worden geëvalueerd. Als beide niveaus een GnuPG-pad bevatten, bepaal dan welke u werkelijk onderhoudt.

Correctie één: herschik de vermeldingen

De precieze correctie is de bedoelde GnuPG-map laten winnen. Open de omgevingsvariabelen voor de gebruiker, bewerk Path en verplaats de GnuPG-pub-map boven de Git-vermeldingen. Open daarna een nieuw PowerShell-venster, want het draaiende venster houdt nog de oude lijst vast.

Het alternatief is een tijdelijke schone omgeving voor de installatie: verwijder de Git-vermeldingen, open een nieuwe shell, voer choco install openvpn uit en zet ze daarna terug.

Beide benaderingen werken om dezelfde reden, en de tweede is alleen veilig als u de vermeldingen echt terugzet. Het verwijderen van Gits usr/bin uit PATH breekt ondertekende commits permanent, en de volgende tool die een werkende gpg verwacht, mislukt met een eigen melding die niets met OpenVPN te maken heeft. Als u de tijdelijke route neemt, bewaar dan de oorspronkelijke waarde van Path in het ticket zodat het herstel een plakactie is en geen reconstructie. De vermeldingen ordenen is de duurzame correctie; ze verwijderen is een omweg met een houdbaarheidsdatum.

Controleer en zet het daarna terug

Controleer voor en na in dezelfde gebruikerscontext die Chocolatey zal gebruiken. where.exe gpg vermeldt elke overeenkomst in resolutievolgorde, dus de eerste regel is degene die wordt uitgevoerd; Get-Command gpg -All geeft hetzelfde antwoord met meer detail in PowerShell. Daarna bevestigt gpg --version welke build heeft geantwoord.

Als where.exe nog steeds de Git-kopie als eerste vermeldt, heeft de herschikking die sessie niet bereikt, en geen enkele herinstallatie helpt. Controleer zowel de machine- als de gebruiker-PATH met [Environment]::GetEnvironmentVariable('Path','Machine') en dezelfde aanroep met 'User', omdat de effectieve lijst uit beide wordt samengesteld. Controleer na een geslaagde installatie opnieuw met openvpn --version en start de service of GUI één keer, omdat een pakket schoon kan installeren en toch een service kan achterlaten die niet start.

Als een correct geordende PATH nog steeds mislukt, is de resterende variabele de pakketversie. Een vastgezet Chocolatey-pakket verwacht misschien een specifieke GnuPG-build of installatiepad die uw machine niet heeft.

Lees het eigen logboek van het pakket voordat u iets anders wijzigt. C:\ProgramData\chocolatey\logs\chocolatey.log registreert de opdrachtregel die mislukte en de map van waaruit die werd uitgevoerd, wat u vertelt of de mislukte oproep een handtekeningcontrole, een extractie of een post-installatiescript was. Dat onderscheid bepaalt of u überhaupt nog gpg debugt.

De gewoonte die herhaling voorkomt is PATH te behandelen als gedeelde toestand met een gedocumenteerde volgorde in plaats van als een zak mappen. Wanneer u een tool installeert die een gangbare binaire naam meebrengt, controleer dan wat die overschaduwt in de volgende shell die u opent. Schrijf daarna de volgorde op die u hebt gekozen, want de volgende installer zal eraan toevoegen en de volgende persoon zal zich afvragen waarom een handtekeningcontrole mislukt op een machine waar niets is veranderd. Eén where.exe voor de installatie bespaart de hele lus.