Installation af OpenVPN fejler, fordi Gits gpg vinder på PATH

En OpenVPN-installation, der dør under Chocolatey med en signerings- eller nøglefejl, er normalt ikke et downloadproblem. Pakken kører et verifikationstrin, der kalder gpg, og Windows opløser det blotte navn gennem PATH. Hvis Git for Windows blev installeret først, sidder dets medfølgende gpg.exe foran det GnuPG-build, som OpenVPN forventer, og det forkerte program svarer på kaldet. Den fejl, du ser, er, hvad det andet program besluttede at klage over, og derfor nævner den aldrig den egentlige årsag.

Rækkefølgen i PATH afgør, hvilken gpg der kører

Windows har ingen central registrering af eksekverbare navne. Når en proces beder om gpg uden en fuld sti, gennemgår loaderen PATH-posterne i rækkefølge og kører det første match. Git for Windows leverer et minimalt GnuPG-build i sin usr/bin-mappe, så signerede commits virker, og dets installationsprogram placerer normalt den mappe nær begyndelsen af brugerens PATH.

GnuPG installerer i sin egen mappe, typisk C:\Program Files (x86)\GNU\GnuPG\pub, og den post kan ligge længere nede på listen eller mangle helt i brugerens PATH. De to programmer deler et navn og en stor del af en kommandolinjeflade, men ikke deres tilstand: Git-buildet leder efter en nøglering et andet sted, kan være en anden version og accepterer måske ikke de valgmuligheder, som installationsprogrammet sender. Den uoverensstemmelse viser sig som en signerings- eller nøglefejl, hvilket er en sandfærdig rapport om, hvad den forkerte binære fil så. Intet i meddelelsen peger på loaderen, fordi loaderen gjorde præcis, hvad den blev bedt om.

Hvorfor det shell, du starter fra, afgør resultatet

Arvereglen er den del, der er værd at internalisere. En underordnet proces får miljøet fra det shell, der startede den, så den rækkefølge, der betyder noget, er rækkefølgen i det øjeblik Chocolatey starter, ikke rækkefølgen efter du har rettet den.

Det er derfor, at redigering af PATH i et indstillingsvindue og genkørsel af installationen i samme terminal ofte ikke ændrer noget: terminalen beholdt det gamle miljø. Start et nyt shell efter enhver ændring, og bekræft med where.exe gpg i det nye shell, før du prøver igen. Det er også derfor, at en post på maskinniveau kan slå en ændring på brugerniveau, da nogle installationsprogrammer tilføjer til begyndelsen af maskinens PATH, og maskinposter vurderes før brugerposter. Hvis begge niveauer indeholder en GnuPG-sti, skal du beslutte, hvilken du faktisk vedligeholder.

Rettelse et: omarranger posterne

Den præcise rettelse er at få den tilsigtede GnuPG-mappe til at vinde. Åbn miljøvariablerne for brugeren, rediger Path, og flyt GnuPG-pub-mappen op over Git-posterne. Åbn derefter et nyt PowerShell-vindue, fordi det kørende stadig holder den gamle liste.

Alternativet er et midlertidigt rent miljø til installationen: fjern Git-posterne, åbn et nyt shell, kør choco install openvpn, og gendan dem derefter.

Begge fremgangsmåder virker af samme grund, og den anden er kun sikker, hvis du faktisk gendanner posterne. Fjernelse af Gits usr/bin fra PATH bryder signerede commits permanent, og det næste værktøj, der forventer en fungerende gpg, fejler med sin egen meddelelse, som intet har med OpenVPN at gøre. Hvis du tager den midlertidige vej, skal du gemme den oprindelige værdi af Path i sagen, så gendannelsen er en indsættelse og ikke en rekonstruktion. At ordne posterne er den holdbare rettelse; at slette dem er en omgåelse med en udløbsdato.

Bekræft, og sæt det så tilbage

Bekræft før og efter i samme brugerkontekst, som Chocolatey vil bruge. where.exe gpg viser hvert match i opløsningsrækkefølge, så den første linje er den, der kører; Get-Command gpg -All giver samme svar med flere detaljer i PowerShell. Derefter bekræfter gpg --version, hvilket build der svarede.

Hvis where.exe stadig viser Git-kopien først, er omarrangeringen ikke nået til den session, og ingen mængde geninstallation hjælper. Tjek både maskin- og bruger-PATH med [Environment]::GetEnvironmentVariable('Path','Machine') og samme kald med 'User', fordi den effektive liste samles fra begge. Efter en vellykket installation skal du tjekke igen med openvpn --version og starte tjenesten eller GUI’en én gang, da en pakke kan installere rent og alligevel efterlade en tjeneste, der ikke starter.

Hvis en korrekt ordnet PATH stadig fejler, er den resterende variabel pakkeversionen. En fastlåst Chocolatey-pakke forventer måske et bestemt GnuPG-build eller en installationssti, som din maskine ikke har.

Læs pakkens egen log, før du ændrer noget andet. C:\ProgramData\chocolatey\logs\chocolatey.log registrerer den kommandolinje, der fejlede, og den mappe, den blev kørt fra, hvilket fortæller dig, om det fejlende kald var en signeringskontrol, en udpakning eller et script efter installationen. Den sondring afgør, om du overhovedet stadig fejlfinder gpg.

Den vane, der forhindrer en gentagelse, er at behandle PATH som delt tilstand med en dokumenteret rækkefølge i stedet for som en pose mapper. Når du installerer et værktøj, der medbringer et almindeligt binært navn, skal du tjekke, hvad det skygger for i det næste shell, du åbner. Skriv derefter den rækkefølge ned, du landede på, fordi den næste installation føjer til den, og den næste person vil undre sig over, hvorfor en signeringskontrol fejler på en maskine, hvor intet er ændret. Et enkelt where.exe før installationen sparer hele løkken.