OpenVPN diegimas nepavyksta, nes Git gpg laimi PATH kelyje

OpenVPN diegimas, kuris žūva po Chocolatey su parašo ar rakto klaida, paprastai nėra atsisiuntimo problema. Paketas vykdo patikrinimo žingsnį, kuris kviečia gpg, o Windows tą pliką vardą išsprendžia per PATH. Jei Git for Windows buvo įdiegtas pirmas, jo pridedamas gpg.exe stovi prieš GnuPG kompiliaciją, kurios tikisi OpenVPN, ir į kvietimą atsako netinkama programa. Klaida, kurią matote, yra tai, dėl ko ta kita programa nusprendė skųstis, todėl ji niekada nemini tikrosios priežasties.

PATH tvarka nusprendžia, kuri gpg bus paleista

Windows neturi centrinio vykdomųjų vardų registro. Kai procesas prašo gpg be viso kelio, įkėlėjas eina per PATH įrašus iš eilės ir paleidžia pirmą atitikimą. Git for Windows pateikia minimalią GnuPG kompiliaciją savo usr/bin kataloge, kad pasirašyti commit'ai veiktų, o jo diegėjas paprastai padeda tą katalogą netoli vartotojo PATH pradžios.

GnuPG įdiegiama į savo katalogą, paprastai C:\Program Files (x86)\GNU\GnuPG\pub, ir tas įrašas gali būti vėliau sąraše arba visiškai trūkti vartotojo PATH sąraše. Abi programos dalijasi vardu ir didele komandinės eilutės sąsajos dalimi, bet ne savo būsena: Git kompiliacija ieško raktų ryšulio kitur, gali būti kitos versijos ir gali nepriimti diegėjo perduodamų parinkčių. Šis neatitikimas pasireiškia kaip parašo ar rakto klaida, kuri yra teisinga ataskaita apie tai, ką matė netinkamas dvejetainis failas. Nieko pranešime nenurodo įkėlėjo, nes įkėlėjas padarė būtent tai, kas jam buvo liepta.

Kodėl rezultatą lemia apvalkalas, iš kurio pradedate

Paveldėjimo taisyklė yra ta dalis, kurią verta įsisavinti. Vaikinio proceso aplinka gaunama iš jį paleidusio apvalkalo, tad svarbi tvarka yra tvarka tuo metu, kai Chocolatey pradeda, o ne tvarka po jūsų pataisymo.

Štai kodėl PATH redagavimas nustatymų lange ir diegimo pakartojimas tame pačiame terminale dažnai nieko nekeičia: terminalas išlaikė seną aplinką. Po bet kurio pakeitimo paleiskite naują apvalkalą ir prieš bandydami dar kartą patvirtinkite su where.exe gpg tame naujame apvalkale. Tai taip pat priežastis, kodėl mašinos lygio įrašas gali nugalėti vartotojo lygio pakeitimą, nes kai kurie diegėjai prideda į mašinos PATH pradžią, o mašinos įrašai vertinami prieš vartotojo įrašus. Jei abiejuose lygiuose yra GnuPG kelias, nuspręskite, kurį iš tikrųjų prižiūrite.

Pirmasis taisymas: perrikiuokite įrašus

Tikslus taisymas – leisti laimėti numatytam GnuPG katalogui. Atidarykite vartotojo aplinkos kintamuosius, redaguokite Path ir perkelkite GnuPG pub katalogą aukščiau Git įrašų. Tada atidarykite naują PowerShell langą, nes veikiantis vis dar laiko seną sąrašą.

Alternatyva – laikina švari aplinka diegimui: pašalinkite Git įrašus, atidarykite naują apvalkalą, paleiskite choco install openvpn ir tada juos atkurkite.

Abu metodai veikia dėl tos pačios priežasties, o antrasis saugus tik jei iš tikrųjų atkuriate įrašus. Git usr/bin pašalinimas iš PATH visam laikui sugadina pasirašytus commit'us, o kitas įrankis, tikėdamasis veikiančio gpg, nepavyksta su savo pranešimu, neturinčiu nieko bendra su OpenVPN. Jei renkatės laikiną kelią, išsaugokite pradinę Path reikšmę biliete, kad atkūrimas būtų įklijavimas, o ne perstatymas. Įrašų rikiavimas yra ilgalaikis taisymas; jų trynimas yra apėjimas su terminu.

Patikrinkite, tada grąžinkite atgal

Patikrinkite prieš ir po toje pačioje vartotojo konteksto aplinkoje, kurią naudos Chocolatey. where.exe gpg išvardija kiekvieną atitikimą sprendimo tvarka, tad pirmoji eilutė yra ta, kuri bus paleista; Get-Command gpg -All PowerShell aplinkoje pateikia tą patį atsakymą išsamiau. Tada gpg --version patvirtina, kuri kompiliacija atsakė.

Jei where.exe vis dar pirmą išvardija Git kopiją, perrikiavimas nepasiekė tos sesijos, ir joks diegimas iš naujo nepadės. Patikrinkite ir mašinos, ir vartotojo PATH su [Environment]::GetEnvironmentVariable('Path','Machine') ir tą patį kvietimą su 'User', nes efektyvus sąrašas surenkamas iš abiejų. Po sėkmingo diegimo dar kartą patikrinkite su openvpn --version ir vieną kartą paleiskite paslaugą arba GUI, nes paketas gali įsirengti švariai ir vis tiek palikti paslaugą, kuri nepasileis.

Jei teisingai surikiuotas PATH vis tiek nepavyksta, likęs kintamasis yra paketo versija. Užfiksuotas Chocolatey paketas gali tikėtis konkrečios GnuPG kompiliacijos ar diegimo kelio, kurio jūsų mašina neturi.

Perskaitykite paties paketo žurnalą prieš ką nors kita keisdami. C:\ProgramData\chocolatey\logs\chocolatey.log įrašo nepavykusią komandų eilutę ir katalogą, iš kurio ji buvo paleista, o tai pasako, ar nepavykęs kvietimas buvo parašo patikrinimas, ištraukimas ar po diegimo vykdomas scenarijus. Šis skirtumas nulemia, ar jūs dar apskritai derinate gpg.

Įprotis, kuris apsaugo nuo pasikartojimo, yra laikyti PATH bendra būsena su dokumentuota tvarka, o ne katalogų maišu. Kai diegiate įrankį, atnešantį įprastą dvejetainį vardą, patikrinkite, ką jis užstoja kitame apvalkale, kurį atidarysite. Tada užsirašykite tvarką, prie kurios sustojote, nes kitas diegėjas ją papildys ir kitas žmogus stebėsis, kodėl parašo patikrinimas nepavyksta mašinoje, kurioje nieko nepasikeitė. Vienas where.exe prieš diegimą sutaupo visą ciklą.