Installasjon av OpenVPN mislukkast fordi gpg hjå Git vinn på PATH

Ein OpenVPN-installasjon som døyr under Chocolatey med ein signerings- eller nøkkelfeil er vanlegvis ikkje eit nedlastingsproblem. Pakken køyrer eit stadfestingstrinn som kallar gpg, og Windows løyser det namnet gjennom PATH. Viss Git for Windows vart installert fyrst, står den medfølgjande gpg.exe framfor GnuPG-bygget som OpenVPN ventar, og feil program svarar på kallet. Feilen du ser, er det det andre programmet bestemte seg for å klaga på, og difor nemner han aldri den eigentlege årsaka.

Rekkjefølgja i PATH avgjer kva gpg som køyrer

Windows har inga sentral registrering av køyrbare namn. Når ein prosess ber om gpg utan full stig, går innlastaren gjennom PATH-oppføringane i rekkjefølgje og køyrer den fyrste treffet. Git for Windows leverer eit minimalt GnuPG-bygg i usr/bin-mappa si slik at signerte commit fungerer, og installatøren plasserer vanlegvis den mappa nær byrjinga av PATH hjå brukaren.

GnuPG installerer i si eiga mappe, vanlegvis C:\Program Files (x86)\GNU\GnuPG\pub, og den oppføringa kan liggja lenger nede på lista eller mangla heilt i PATH hjå brukaren. Dei to programma deler eit namn og store delar av eit kommandolinjegrensesnitt, men ikkje tilstanden sin: Git-bygget leitar etter ein nøkkelring ein annan stad, kan vera ein annan versjon og godtek kanskje ikkje vala installatøren sender. Det misforholdet syner seg som ein signerings- eller nøkkelfeil, som er ein sannferdig rapport om kva den gale binære fila såg. Ingenting i meldinga peikar på innlastaren, fordi innlastaren gjorde nøyaktig det han vart beden om.

Kvifor skalet du startar frå avgjer resultatet

Arveregelen er den delen det er verdt å internalisera. Ein underordna prosess får miljøet til skalet som starta han, så rekkjefølgja som tel er rekkjefølgja i augneblinken Chocolatey startar, ikkje rekkjefølgja etter at du har retta henne.

Difor endrar redigering av PATH i eit innstillingsvindauge og ny køyring av installasjonen i same terminal ofte ingenting: terminalen heldt på det gamle miljøet. Start eit nytt skal etter kvar endring, og stadfest med where.exe gpg i det nye skalet før du prøver igjen. Det er også difor ei oppføring på maskinnivå kan slå ei endring på brukarnivå, sidan nokre installatørar legg til i byrjinga av maskina sin PATH, og maskinoppføringar vert vurderte før brukaroppføringar. Viss begge nivåa inneheld ein GnuPG-stig, må du avgjera kva du faktisk vedlikeheld.

Rettelse éin: omorganiser oppføringane

Den presise rettelsen er å få den tiltenkte GnuPG-mappa til å vinna. Opne miljøvariablane for brukaren, rediger Path og flytt GnuPG-pub-mappa over Git-oppføringane. Opne deretter eit nytt PowerShell-vindauge, fordi det som køyrer framleis held på den gamle lista.

Alternativet er eit mellombels reint miljø for installasjonen: fjern Git-oppføringane, opne eit nytt skal, køyr choco install openvpn og set dei deretter tilbake.

Begge tilnærmingane verkar av same grunn, og den andre er berre trygg viss du faktisk set oppføringane tilbake. Fjerning av Gits usr/bin frå PATH øydelegg signerte commit permanent, og det neste verktøyet som ventar ein fungerande gpg, mislukkast med si eiga melding som ikkje har noko med OpenVPN å gjera. Viss du tek den mellombelse vegen, ta vare på den opphavlege verdien av Path i saka slik at gjenopprettinga er ei innliming og ikkje ein gjenoppbygging. Å ordna oppføringane er den varige rettelsen; å sletta dei er ein omveg med utløpsdato.

Stadfest, og set det deretter tilbake

Stadfest før og etter i same brukarkontekst som Chocolatey vil bruka. where.exe gpg viser kvart treff i oppløysingsrekkjefølgje, så den fyrste linja er den som køyrer; Get-Command gpg -All gjev same svar med fleire detaljar i PowerShell. Deretter stadfestar gpg --version kva bygg som svara.

Viss where.exe framleis viser Git-kopien fyrst, har omorganiseringa ikkje nådd den økta, og inga mengd nyinstallering hjelper. Sjekk både maskin- og brukar-PATH med [Environment]::GetEnvironmentVariable('Path','Machine') og same kall med 'User', fordi den effektive lista vert sett saman frå begge. Etter ein vellukka installasjon, sjekk på nytt med openvpn --version og start tenesta eller GUI-et éin gong, sidan ein pakke kan installera reint og likevel etterlata ei teneste som ikkje startar.

Viss ein korrekt ordna PATH framleis mislukkast, er den gjenverande variabelen pakkeversjonen. Ein fastlåst Chocolatey-pakke ventar kanskje eit bestemt GnuPG-bygg eller ein installasjonsstig som maskina di ikkje har.

Les den eigen loggen til pakken før du endrar noko anna. C:\ProgramData\chocolatey\logs\chocolatey.log registrerer kommandolinja som mislukkast og mappa ho vart køyrd frå, noko som fortel deg om det mislukka kallet var ein signeringssjekk, ei utpakking eller eit skript etter installasjonen. Den skilnaden avgjer om du i det heile framleis feilsøkjer gpg.

Vana som hindrar gjentaking er å handsama PATH som delt tilstand med ei dokumentert rekkjefølgje i staden for som ein pose med mapper. Når du installerer eit verktøy som bringar med seg eit vanleg binærnamn, sjekk kva det skuggar for i det neste skalet du opnar. Skriv deretter ned rekkjefølgja du landa på, fordi den neste installatøren vil leggja til i henne, og den neste personen vil undra seg over kvifor ein signeringssjekk mislukkast på ei maskin der ingenting er endra. Eitt where.exe før installasjonen sparer heile løkka.