Namestitev OpenVPN ne uspe, ker gpg iz Gita zmaga na PATH

Namestitev OpenVPN, ki pod Chocolateyjem umre z napako podpisa ali ključa, običajno ni težava s prenosom. Paket izvede korak preverjanja, ki pokliče gpg, in Windows to golo ime razreši prek PATH. Če je bil Git for Windows nameščen prvi, njegov priloženi gpg.exe stoji pred gradnjo GnuPG, ki jo OpenVPN pričakuje, in na klic odgovori napačen program. Napaka, ki jo vidite, je tisto, zaradi česar se je ta drugi program odločil pritožiti, zato nikoli ne navaja pravega vzroka.

Vrstni red v PATH odloča, kateri gpg se zažene

Windows nima osrednjega registra imen izvršljivih datotek. Ko proces zahteva gpg brez polne poti, nalagalnik prehodi vnose v PATH po vrsti in zažene prvo ujemanje. Git for Windows prinaša minimalno gradnjo GnuPG v svoji mapi usr/bin, da podpisani commiti delujejo, in njegov namestnik običajno to mapo postavi blizu začetka uporabnikovega PATH.

GnuPG se namesti v svojo mapo, običajno C:\Program Files (x86)\GNU\GnuPG\pub, in ta vnos je lahko pozneje na seznamu ali pa v uporabnikovem PATH povsem manjka. Oba programa si delita ime in velik del vmesnika ukazne vrstice, ne pa svojega stanja: gradnja Git išče obesek za ključe drugje, je morda druge različice in morda ne sprejema možnosti, ki jih posreduje namestnik. To neskladje se pokaže kot napaka podpisa ali ključa, kar je resnično poročilo o tem, kaj je videl napačni binarni file. Nič v sporočilu ne kaže na nalagalnik, ker je nalagalnik naredil točno to, kar mu je bilo rečeno.

Zakaj lupina, iz katere začnete, odloči o izidu

Pravilo dedovanja je del, ki si ga je vredno privzgojiti. Podrejeni proces dobi okolje lupine, ki ga je zagnala, zato je odločilen vrstni red v trenutku, ko se Chocolatey zažene, ne vrstni red po vašem popravku.

Zato urejanje PATH v oknu z nastavitvami in ponovno izvajanje namestitve v istem terminalu pogosto ne spremeni ničesar: terminal je obdržal staro okolje. Po vsaki spremembi zaženite novo lupino in pred ponovnim poskusom potrdite z where.exe gpg v tej novi lupini. To je tudi razlog, da lahko vnos na ravni stroja premaga spremembo na ravni uporabnika, saj nekateri namestniki dodajajo na začetek PATH stroja in se vnosi stroja ovrednotijo pred uporabniškimi. Če obe ravni vsebujeta pot GnuPG, se odločite, katero dejansko vzdržujete.

Prvi popravek: preuredite vnose

Natančen popravek je, da zmaga želena mapa GnuPG. Odprite okoljske spremenljivke za uporabnika, uredite Path in premaknite mapo pub GnuPG nad vnose Git. Nato odprite novo okno PowerShell, ker to, ki teče, še vedno drži stari seznam.

Alternativa je začasno čisto okolje za namestitev: odstranite vnose Git, odprite novo lupino, zaženite choco install openvpn in jih nato obnovite.

Oba pristopa delujeta iz istega razloga, drugi pa je varen le, če vnose res obnovite. Odstranitev Gitovega usr/bin iz PATH trajno pokvari podpisane commite in naslednje orodje, ki pričakuje delujoč gpg, spodleti z lastnim sporočilom, ki nima nič skupnega z OpenVPN. Če izberete začasno pot, shranite prvotno vrednost Path v zahtevku, da bo obnovitev prilepitev in ne ponovna izgradnja. Urejanje vrstnega reda vnosov je trajen popravek; njihovo brisanje je obhod z rokom uporabe.

Preverite in nato vrnite nazaj

Preverite pred in po v istem uporabniškem kontekstu, ki ga bo uporabil Chocolatey. where.exe gpg navaja vsako ujemanje v vrstnem redu razrešitve, zato je prva vrstica tista, ki se bo zagnala; Get-Command gpg -All da v PowerShellu enak odgovor z več podrobnostmi. Nato gpg --version potrdi, katera gradnja je odgovorila.

Če where.exe še vedno navaja kopijo Git prvo, preureditev ni dosegla te seje in nobena ponovna namestitev ne bo pomagala. Preverite PATH stroja in uporabnika z [Environment]::GetEnvironmentVariable('Path','Machine') ter isti klic z 'User', ker je učinkovit seznam sestavljen iz obeh. Po uspešni namestitvi znova preverite z openvpn --version in enkrat zaženite storitev ali GUI, ker se paket lahko namesti čisto in vseeno pusti storitev, ki se ne bo zagnala.

Če pravilno urejen PATH še vedno spodleti, je preostala spremenljivka različica paketa. Pripet paket Chocolatey lahko pričakuje določeno gradnjo GnuPG ali pot namestitve, ki je vaš stroj nima.

Preberite lastni dnevnik paketa, preden spremenite karkoli drugega. C:\ProgramData\chocolatey\logs\chocolatey.log zabeleži ukazno vrstico, ki je spodletela, in mapo, iz katere je bila zagnana, kar vam pove, ali je bil neuspešni klic preverjanje podpisa, izluščenje ali skript po namestitvi. Ta razlika odloči, ali sploh še odpravljate napake v gpg.

Navada, ki preprečuje ponovitev, je obravnavati PATH kot deljeno stanje z dokumentiranim vrstnim redom, ne kot vrečo map. Ko nameščate orodje, ki prinaša pogosto binarno ime, preverite, kaj zasenči v naslednji lupini, ki jo odprete. Nato zapišite vrstni red, na katerem ste se ustavili, ker bo naslednji namestnik dodal k njemu in naslednja oseba se bo spraševala, zakaj preverjanje podpisa spodleti na stroju, kjer se ni nič spremenilo. En where.exe pred namestitvijo prihrani celoten cikel.