OpenVPN-installasie misluk omdat Git se gpg op PATH wen

’n OpenVPN-installasie wat onder Chocolatey met ’n ondertekenings- of sleutfout sterf, is gewoonlik nie ’n aflaaiprobleem nie. Die pakket voer ’n verifikasiestap uit wat gpg aanroep, en Windows los daardie kaal naam deur PATH op. As Git for Windows eerste geïnstalleer is, sit sy meegeleverde gpg.exe voor die GnuPG-bou wat OpenVPN verwag, en die verkeerde program antwoord die oproep. Die fout wat jy sien, is wat daardie ander program ook al besluit het om oor te kla, en daarom noem dit nooit die werklike oorsaak nie.

PATH-volgorde bepaal watter gpg loop

Windows het geen sentrale register van uitvoerbare name nie. Wanneer ’n proses gpg sonder ’n volledige pad aanvra, loop die laaier die PATH-inskrywings in volgorde deur en voer die eerste treffer uit. Git for Windows lewer ’n minimale GnuPG-bou in sy usr/bin-gids sodat ondertekende commits werk, en sy installeerder plaas daardie gids gewoonlik naby die voorkant van die gebruiker se PATH.

GnuPG installeer in sy eie gids, gewoonlik C:\Program Files (x86)\GNU\GnuPG\pub, en daardie inskrywing kan later in die lys wees of heeltemal uit die gebruiker se PATH ontbreek. Die twee programme deel ’n naam en baie van ’n opdragreël-oppervlak, maar nie hul toestand nie: die Git-bou soek ’n sleutelring êrens anders, is dalk ’n ander weergawe, en aanvaar dalk nie die opsies wat die installeerder deurgee nie. Daardie wanverhouding kom na vore as ’n ondertekenings- of sleutfout, wat ’n waarheidsgetroue verslag is van wat die verkeerde binêre lêer gesien het. Niks in die boodskap wys na die laaier nie, want die laaier het presies gedoen wat vir hom gesê is.

Waarom die dop waarin jy begin die uitslag bepaal

Die oorerwingsreël is die deel wat werd is om te internaliseer. ’n Kindproses kry die omgewing van die dop wat dit begin het, so die volgorde wat saak maak, is die volgorde op die oomblik wanneer Chocolatey begin, nie die volgorde nadat jy dit reggemaak het nie.

Dit is waarom die redigering van PATH in ’n instellingsvenster en die heruitvoering van die installasie in dieselfde terminaal dikwels niks verander nie: die terminaal het die ou omgewing behou. Begin ’n nuwe dop ná enige wysiging, en bevestig met where.exe gpg in daardie nuwe dop voordat jy weer probeer. Dit is ook waarom ’n masjienvlak-inskrywing ’n gebruikervlak-wysiging kan klop, aangesien sommige installeerders by die masjien se PATH voorvoeg en masjieninskrywings voor gebruikersinskrywings geëvalueer word. As albei vlakke ’n GnuPG-pad bevat, besluit watter een jy werklik onderhou.

Regstelling een: herrangskik die inskrywings

Die presiese regstelling is om die bedoelde GnuPG-gids te laat wen. Maak die omgewingsveranderlikes vir die gebruiker oop, redigeer Path, en skuif die GnuPG-pub-gids bo die Git-inskrywings. Maak dan ’n vars PowerShell-venster oop, want die lopende een hou steeds die ou lys vas.

Die alternatief is ’n tydelike skoon omgewing vir die installasie: haal die Git-inskrywings uit, maak ’n nuwe dop oop, voer choco install openvpn uit en sit hulle dan terug.

Albei benaderings werk om dieselfde rede, en die tweede een is net veilig as jy die inskrywings werklik terug sit. Om Git se usr/bin uit PATH te verwyder, breek ondertekende commits permanent, en die volgende instrument wat ’n werkende gpg verwag, misluk met sy eie boodskap wat niks met OpenVPN te doen het nie. As jy die tydelike roete volg, hou die oorspronklike waarde van Path in die kaartjie sodat die herstel ’n plak is eerder as ’n herkonstruksie. Om die inskrywings te orden is die duursame regstelling; om hulle te skrap is ’n noodoplossing met ’n sperdatum.

Verifieer, en sit dit dan terug

Verifieer voor en ná met dieselfde gebruikerkonteks wat Chocolatey sal gebruik. where.exe gpg lys elke treffer in resolusievolgorde, so die eerste reël is die een wat sal loop; Get-Command gpg -All gee dieselfde antwoord met meer besonderhede in PowerShell. Dan bevestig gpg --version watter bou geantwoord het.

As where.exe die Git-kopie steeds eerste lys, dan het die herrangskikking daardie sessie nie bereik nie, en geen hoeveelheid herinstallasie sal help nie. Kontroleer beide die masjien- en gebruiker-PATH met [Environment]::GetEnvironmentVariable('Path','Machine') en dieselfde oproep met 'User', want die effektiewe lys word uit albei saamgestel. Herkontroleer ná ’n suksesvolle installasie met openvpn --version en begin die diens of GUI een keer, aangesien ’n pakket skoon kan installeer en steeds ’n diens kan los wat nie sal begin nie.

As ’n korrek geordende PATH steeds misluk, is die oorblywende veranderlike die pakketweergawe. ’n Vasgepende Chocolatey-pakket verwag dalk ’n spesifieke GnuPG-bou of installasiepad wat jou masjien nie het nie.

Lees die pakket se eie log voordat jy enigiets anders verander. C:\ProgramData\chocolatey\logs\chocolatey.log teken die opdragreël wat misluk het en die gids waaruit dit gehardloop het aan, wat jou vertel of die mislukte oproep ’n ondertekeningskontrole, ’n uitpak of ’n na-installasie-skrip was. Daardie onderskeid bepaal of jy hoegenaamd nog gpg ontfout.

Die gewoonte wat ’n herhaling voorkom, is om PATH as gedeelde toestand met ’n gedokumenteerde volgorde te behandel eerder as ’n sak gidse. Wanneer jy ’n instrument installeer wat ’n algemene binêre naam meebring, kyk wat dit in die volgende dop wat jy oopmaak, oorskadu. Skryf dan die volgorde neer waarop jy besluit het, want die volgende installeerder sal daarby voeg en die volgende persoon sal wonder waarom ’n ondertekeningskontrole misluk op ’n masjien waar niks verander het nie. Een where.exe voor die installasie spaar die hele lus.