OpenVPN instalēšana neizdodas, jo Git gpg uzvar PATH

OpenVPN instalācija, kas zem Chocolatey nomirst ar paraksta vai atslēgas kļūdu, parasti nav lejupielādes problēma. Pakotne veic pārbaudes soli, kas izsauc gpg, un Windows šo kailo nosaukumu atrisina caur PATH. Ja Git for Windows tika instalēts pirmais, tā pievienotais gpg.exe atrodas pirms GnuPG būvējuma, ko OpenVPN sagaida, un uz izsaukumu atbild nepareizā programma. Kļūda, ko redzat, ir tas, par ko šī otra programma nolēma sūdzēties, tāpēc tā nekad nemin īsto iemeslu.

PATH secība nosaka, kurš gpg tiek palaists

Windows nav centralizēta izpildāmo nosaukumu reģistra. Kad process pieprasa gpg bez pilna ceļa, ielādētājs secīgi iziet cauri PATH ierakstiem un palaiž pirmo atbilstību. Git for Windows piegādā minimālu GnuPG būvējumu savā usr/bin mapē, lai parakstīti commit darbotos, un tā instalētājs parasti ievieto šo mapi netālu no lietotāja PATH sākuma.

GnuPG instalējas savā mapē, parasti C:\Program Files (x86)\GNU\GnuPG\pub, un šis ieraksts var būt tālāk sarakstā vai pilnībā trūkt lietotāja PATH. Abas programmas dala nosaukumu un lielu daļu komandrindas saskarnes, bet ne savu stāvokli: Git būvējums meklē atslēgu saišķi citur, var būt citā versijā un var nepieņemt opcijas, ko instalētājs nodod. Šī neatbilstība izpaužas kā paraksta vai atslēgas kļūda, kas ir patiess ziņojums par to, ko redzēja nepareizais binārais fails. Nekas ziņojumā nenorāda uz ielādētāju, jo ielādētājs izdarīja tieši to, kas tam tika teikts.

Kāpēc rezultātu nosaka čaula, no kuras sākat

Mantošanas noteikums ir tā daļa, ko ir vērts iekšēji pārņemt. Bērna process saņem tās čaulas vidi, kas to palaida, tāpēc svarīgā secība ir secība brīdī, kad Chocolatey sākas, nevis secība pēc jūsu labojuma.

Tāpēc PATH rediģēšana iestatījumu logā un instalācijas atkārtota palaišana tajā pašā terminālī bieži neko nemaina: terminālis saglabāja veco vidi. Pēc jebkuras izmaiņas sāciet jaunu čaulu un pirms mēģināt vēlreiz apstipriniet ar where.exe gpg tajā jaunajā čaulā. Tas ir arī iemesls, kāpēc mašīnas līmeņa ieraksts var pārspēt lietotāja līmeņa izmaiņas, jo daži instalētāji pievieno mašīnas PATH sākumam, un mašīnas ieraksti tiek vērtēti pirms lietotāja ierakstiem. Ja abos līmeņos ir GnuPG ceļš, izlemiet, kuru jūs patiešām uzturat.

Pirmais labojums: pārkārtojiet ierakstus

Precīzais labojums ir likt uzvarēt paredzētajai GnuPG mapei. Atveriet lietotāja vides mainīgos, rediģējiet Path un pārvietojiet GnuPG pub mapi virs Git ierakstiem. Pēc tam atveriet jaunu PowerShell logu, jo darbojošais vēl tur veco sarakstu.

Alternatīva ir pagaidu tīra vide instalācijai: izņemiet Git ierakstus, atveriet jaunu čaulu, palaidiet choco install openvpn un pēc tam atjaunojiet tos.

Abas pieejas darbojas viena un tā paša iemesla dēļ, un otrā ir droša tikai tad, ja jūs tiešām atjaunojat ierakstus. Git usr/bin izņemšana no PATH neatgriezeniski salauž parakstītos commit, un nākamais rīks, kas sagaida strādājošu gpg, neizdodas ar savu ziņojumu, kam nav nekāda sakara ar OpenVPN. Ja izvēlaties pagaidu ceļu, saglabājiet Path sākotnējo vērtību biļetē, lai atjaunošana būtu ielīmēšana, nevis pārbūve. Ierakstu sakārtošana ir ilgtermiņa labojums; to dzēšana ir apiešana ar termiņu.

Pārbaudiet un pēc tam nolieciet atpakaļ

Pārbaudiet pirms un pēc tajā pašā lietotāja kontekstā, ko izmantos Chocolatey. where.exe gpg uzskaita katru atbilstību atrisināšanas secībā, tāpēc pirmā rinda ir tā, kas tiks palaista; Get-Command gpg -All PowerShell sniedz to pašu atbildi ar vairāk detaļu. Pēc tam gpg --version apstiprina, kurš būvējums atbildēja.

Ja where.exe joprojām pirmo uzskaita Git kopiju, pārkārtošana nav sasniegusi šo sesiju, un nekāda pārinstalēšana nepalīdzēs. Pārbaudiet gan mašīnas, gan lietotāja PATH ar [Environment]::GetEnvironmentVariable('Path','Machine') un to pašu izsaukumu ar 'User', jo efektīvais saraksts tiek salikts no abiem. Pēc veiksmīgas instalācijas vēlreiz pārbaudiet ar openvpn --version un vienreiz palaidiet pakalpojumu vai GUI, jo pakotne var instalēties tīri un tomēr atstāt pakalpojumu, kas neieslēgsies.

Ja pareizi sakārtots PATH joprojām neizdodas, atlikušais mainīgais ir pakotnes versija. Piespraustā Chocolatey pakotne var sagaidīt konkrētu GnuPG būvējumu vai instalācijas ceļu, kā jūsu mašīnai nav.

Lasiet pašas pakotnes žurnālu pirms kaut ko citu maināt. C:\ProgramData\chocolatey\logs\chocolatey.log ieraksta neizdevušos komandrindu un mapi, no kuras tā tika palaista, kas jums pasaka, vai neizdevušais izsaukums bija paraksta pārbaude, izvilkšana vai pēcininstalācijas skripts. Šī atšķirība nosaka, vai jūs vispār vēl atkļūdojat gpg.

Ieradums, kas novērš atkārtošanos, ir attiekties pret PATH kā pret koplietotu stāvokli ar dokumentētu secību, nevis kā pret mapju maisu. Kad instalējat rīku, kas nes sev līdzi izplatītu bināro nosaukumu, pārbaudiet, ko tas aizēno nākamajā čaulā, kuru atverat. Pēc tam pierakstiet secību, pie kuras apstājāties, jo nākamais instalētājs to papildinās un nākamais cilvēks brīnīsies, kāpēc paraksta pārbaude neizdodas mašīnā, kur nekas nav mainījies. Viens where.exe pirms instalācijas ietaupa visu ciklu.