Installasjon av OpenVPN mislykkes fordi Gits gpg vinner på PATH

En OpenVPN-installasjon som dør under Chocolatey med en signerings- eller nøkkelfeil er vanligvis ikke et nedlastingsproblem. Pakken kjører et verifiseringstrinn som kaller gpg, og Windows løser det bare navnet gjennom PATH. Hvis Git for Windows ble installert først, står den medfølgende gpg.exe foran GnuPG-bygget som OpenVPN forventer, og feil program svarer på kallet. Feilen du ser, er det det andre programmet bestemte seg for å klage på, og derfor nevner den aldri den egentlige årsaken.

Rekkefølgen i PATH avgjør hvilken gpg som kjører

Windows har ingen sentral registrering av kjørbare navn. Når en prosess ber om gpg uten full sti, går innlasteren gjennom PATH-oppføringene i rekkefølge og kjører den første treffet. Git for Windows leverer et minimalt GnuPG-bygg i usr/bin-katalogen sin slik at signerte commits fungerer, og installasjonsprogrammet plasserer vanligvis den katalogen nær begynnelsen av brukerens PATH.

GnuPG installerer i sin egen katalog, vanligvis C:\Program Files (x86)\GNU\GnuPG\pub, og den oppføringen kan ligge lenger ned på listen eller mangle helt i brukerens PATH. De to programmene deler et navn og store deler av et kommandolinjegrensesnitt, men ikke tilstanden sin: Git-bygget leter etter en nøkkelring et annet sted, kan være en annen versjon og godtar kanskje ikke alternativene installasjonsprogrammet sender. Det misforholdet viser seg som en signerings- eller nøkkelfeil, som er en sannferdig rapport om hva den gale binærfila så. Ingenting i meldingen peker på innlasteren, fordi innlasteren gjorde nøyaktig det den ble bedt om.

Hvorfor skallet du starter fra avgjør resultatet

Arveregelen er den delen det er verdt å internalisere. En underordnet prosess får miljøet til skallet som startet den, så rekkefølgen som betyr noe er rekkefølgen i det øyeblikket Chocolatey starter, ikke rekkefølgen etter at du har rettet den.

Derfor endrer redigering av PATH i et innstillingsvindu og ny kjøring av installasjonen i samme terminal ofte ingenting: terminalen beholdt det gamle miljøet. Start et nytt skall etter enhver endring, og bekreft med where.exe gpg i det nye skallet før du prøver igjen. Det er også derfor en oppføring på maskinnivå kan slå en endring på brukernivå, siden noen installasjonsprogrammer legger til i begynnelsen av maskinens PATH, og maskinoppføringer vurderes før brukeroppføringer. Hvis begge nivåene inneholder en GnuPG-sti, må du bestemme hvilken du faktisk vedlikeholder.

Rettelse én: omorganiser oppføringene

Den presise rettelsen er å få den tiltenkte GnuPG-katalogen til å vinne. Åpne miljøvariablene for brukeren, rediger Path og flytt GnuPG-pub-katalogen over Git-oppføringene. Åpne deretter et nytt PowerShell-vindu, fordi det som kjører fortsatt holder på den gamle listen.

Alternativet er et midlertidig rent miljø for installasjonen: fjern Git-oppføringene, åpne et nytt skall, kjør choco install openvpn og gjenopprett dem deretter.

Begge tilnærmingene virker av samme grunn, og den andre er bare trygg hvis du faktisk gjenoppretter oppføringene. Fjerning av Gits usr/bin fra PATH ødelegger signerte commits permanent, og det neste verktøyet som forventer en fungerende gpg, mislykkes med sin egen melding som ikke har noe med OpenVPN å gjøre. Hvis du tar den midlertidige veien, ta vare på den opprinnelige verdien av Path i saken slik at gjenopprettingen er en innliming og ikke en gjenoppbygging. Å ordne oppføringene er den varige rettelsen; å slette dem er en omvei med utløpsdato.

Bekreft, og sett det deretter tilbake

Bekreft før og etter i samme brukerkontekst som Chocolatey vil bruke. where.exe gpg viser hvert treff i oppløsningsrekkefølge, så den første linjen er den som kjører; Get-Command gpg -All gir samme svar med flere detaljer i PowerShell. Deretter bekrefter gpg --version hvilket bygg som svarte.

Hvis where.exe fortsatt viser Git-kopien først, har omorganiseringen ikke nådd den økten, og ingen mengde nyinstallering hjelper. Sjekk både maskin- og bruker-PATH med [Environment]::GetEnvironmentVariable('Path','Machine') og samme kall med 'User', fordi den effektive listen settes sammen fra begge. Etter en vellykket installasjon, sjekk på nytt med openvpn --version og start tjenesten eller GUI-et én gang, siden en pakke kan installere rent og likevel etterlate en tjeneste som ikke starter.

Hvis en korrekt ordnet PATH fortsatt mislykkes, er den gjenværende variabelen pakkeversjonen. En fastlåst Chocolatey-pakke forventer kanskje et bestemt GnuPG-bygg eller en installasjonssti som maskinen din ikke har.

Les pakkens egen logg før du endrer noe annet. C:\ProgramData\chocolatey\logs\chocolatey.log registrerer kommandolinjen som mislyktes og katalogen den ble kjørt fra, noe som forteller deg om det mislykkede kallet var en signeringssjekk, en utpakking eller et skript etter installasjonen. Den forskjellen avgjør om du i det hele tatt fortsatt feilsøker gpg.

Vanen som forhindrer gjentakelse er å behandle PATH som delt tilstand med en dokumentert rekkefølge i stedet for som en pose med kataloger. Når du installerer et verktøy som bringer med seg et vanlig binærnavn, sjekk hva det skygger for i det neste skallet du åpner. Skriv deretter ned rekkefølgen du landet på, fordi det neste installasjonsprogrammet vil legge til i den, og den neste personen vil undre seg over hvorfor en signeringssjekk mislykkes på en maskin der ingenting er endret. Ett where.exe før installasjonen sparer hele løkken.