OpenVPN-ynstallaasje mislearret omdat de gpg fan Git wint op PATH

In OpenVPN-ynstallaasje dy’t ûnder Chocolatey stjert mei in ûndertekenings- of kaai-flater is meastentiids gjin downloadprobleem. It pakket rint in ferifikaasjestap dy’t gpg oanropt, en Windows lost dy keale namme op fia PATH. As Git for Windows earst ynstallearre is, stiet syn mei-levere gpg.exe foar de GnuPG-bou dy’t OpenVPN ferwachtet, en it ferkearde programma antwurdet op ’e oprop. De flater dy’t jo sjogge is wat dat oare programma besletten hat om oer te klagen, en dêrom neamt it nea de wiere oarsaak.

PATH-folchoarder bepaalt hokker gpg draait

Windows hat gjin sintraal register fan útfiere namme. As in proses gpg sûnder folslein paad freget, rint de lader de PATH-ynfieringen yn folchoarder troch en draait de earste oerienkomst. Git for Windows levert in minimale GnuPG-bou yn syn usr/bin-map sadat ûndertekene commits wurkje, en syn ynstallearder pleatst dy map meastentiids tichtby it begjin fan ’e PATH fan ’e brûker.

GnuPG ynstallearret yn syn eigen map, meastentiids C:\Program Files (x86)\GNU\GnuPG\pub, en dy ynfiering kin letter yn ’e list stean of hielendal ûntbrekke út ’e PATH fan ’e brûker. De twa programma’s diele in namme en in grut part fan in kommandorigel-ynterface, mar net har steat: de Git-bou siket in kaairing earne oars, is miskien in oare ferzje, en akseptearret miskien net de opsjes dy’t de ynstallearder trochjout. Dy mismatch docht bliken as in ûndertekenings- of kaai-flater, wat in wierheidsgetrou ferslach is fan wat de ferkearde binêre seach. Neat yn ’e berjocht wiist nei de lader, want de lader die krekt wat him sein wie.

Wêrom’t de shell dêr’t jo út starte it resultaat bepaalt

De erfenisregel is it diel dat it wurdich is om te ynternalisearjen. In bernproses krijt de omjouwing fan ’e shell dy’t it starte, dus de folchoarder dy’t fan belang is, is de folchoarder op it momint dat Chocolatey begjint, net de folchoarder neidat jo it reparearre hawwe.

Dêrom feroaret it bewurkjen fan PATH yn in ynstellingsfinster en it opnij draaien fan ’e ynstallaasje yn deselde terminal faak neat: de terminal hold de âlde omjouwing. Start in nije shell nei elke bewurking, en befêstigje mei where.exe gpg yn dy nije shell foardat jo it opnij besykje. Dat is ek wêrom’t in ynfiering op masjinenivo in feroaring op brûkersnivo ferslaan kin, om’t guon ynstallearders foar de PATH fan ’e masjine tafoegje en masjine-ynfieringen foar brûkersynfieringen wurde evaluearre. As beide nivo’s in GnuPG-paad befetsje, beslute hokker jo eins ûnderhâlde.

Reparaasje ien: feroarje de folchoarder fan ’e ynfieringen

De krekte reparaasje is de bedoelde GnuPG-map winne te litten. Iepenje de omjouwingsfariabelen fan ’e brûker, bewurkje Path, en ferpleats de GnuPG-pub-map boppe de Git-ynfieringen. Iepenje dan in nij PowerShell-finster, want it draaiende hâldt noch de âlde list.

It alternatyf is in tydlike skjinne omjouwing foar de ynstallaasje: helje de Git-ynfieringen fuort, iepenje in nije shell, draai choco install openvpn, en set se dan werom.

Beide oanpakken wurkje om deselde reden, en it twadde is allinnich feilich as jo de ynfieringen echt weromsette. It fuortheljen fan Git syn usr/bin út PATH brekt ûndertekene commits permanint, en it folgjende helpmiddel dat in wurkjende gpg ferwachtet, mislearret mei syn eigen berjocht dat neat mei OpenVPN te meitsjen hat. As jo de tydlike wei nimme, bewarje dan de oarspronklike wearde fan Path yn ’e ticket sadat it weromsetten in plak is en gjin weropbou. It oardersjen fan ’e ynfieringen is de duorsume reparaasje; se wiskje is in omwei mei in ferfaldatum.

Ferifiearje, en set it dan werom

Ferifiearje foar en nei yn deselde brûkerskontekst dy’t Chocolatey brûke sil. where.exe gpg listet elke oerienkomst yn oplossingsfolchoarder, dus de earste rigel is dejinge dy’t draaie sil; Get-Command gpg -All jout itselde antwurd mei mear detail yn PowerShell. Dan befêstiget gpg --version hokker bou antwurde.

As where.exe noch altyd de Git-kopy earst listet, hat de folchoarderferoaring dy sesje net berikt, en gjin inkelde weromynstallaasje sil helpe. Kontrolearje sawol de masjine- as brûker-PATH mei [Environment]::GetEnvironmentVariable('Path','Machine') en deselde oprop mei 'User', want de effektive list wurdt út beide gearstald. Nei in suksesfolle ynstallaasje, kontrolearje opnij mei openvpn --version en start de tsjinst of GUI ien kear, om’t in pakket skjin ynstallearje kin en dochs in tsjinst efterlitte dy’t net start.

As in korrekt oardere PATH noch altyd mislearret, is de oerbliuwende fariabele de pakketferzje. In fêstsette Chocolatey-pakket ferwachtet miskien in spesifike GnuPG-bou of ynstallaasjepaad dy’t jo masjine net hat.

Lês it eigen log fan it pakket foardat jo eat oars feroarje. C:\ProgramData\chocolatey\logs\chocolatey.log registrearret de kommandorigel dy’t mislearre en de map dêr’t er út draaide, wat jo fertelt oft de mislearre oprop in ûndertekeningskontrôle, in ekstraksje of in post-ynstallaasjeskript wie. Dat ûnderskie bepaalt oft jo noch hielendal gpg debugge.

De gewoante dy’t in werhelling foarkomt is PATH te behanneljen as dielde steat mei in dokumintearre folchoarder ynstee fan as in ponge mei mappen. As jo in helpmiddel ynstallearje dat in gewoane binêre namme meinimt, kontrolearje wat it yn ’e folgjende shell dy’t jo iepenje yn ’e skaad set. Skriuw dan de folchoarder op dy’t jo keazen hawwe, want de folgjende ynstallearder sil deroan tafoegje en de folgjende persoan sil har ôffreegje wêrom’t in ûndertekeningskontrôle mislearret op in masjine dêr’t neat feroare is. Ien where.exe foar de ynstallaasje sparret de hiele lus.