Instalimi i OpenVPN dështon sepse gpg i Git fiton në PATH

Një instalim i OpenVPN që vdes nën Chocolatey me një gabim nënshkrimi ose çelësi zakonisht nuk është problem shkarkimi. Paketa ekzekuton një hap verifikimi që thërret gpg, dhe Windows e zgjidh atë emër të zhveshur përmes PATH. Nëse Git for Windows u instalua i pari, gpg.exe i tij i bashkangjitur qëndron përpara ndërtimit të GnuPG që pret OpenVPN, dhe programi i gabuar përgjigjet thirrjes. Gabimi që shihni është ajo për të cilën ai program tjetër vendosi të ankohet, prandaj nuk përmend kurrë shkakun e vërtetë.

Rendi i PATH vendos cili gpg ekzekutohet

Windows nuk ka një regjistër qendror të emrave të ekzekutueshëm. Kur një proces kërkon gpg pa shteg të plotë, ngarkuesi kalon nëpër hyrjet e PATH me radhë dhe ekzekuton përputhjen e parë. Git for Windows ofron një ndërtim minimal GnuPG brenda drejtorisë së tij usr/bin që commit-et e nënshkruara të funksionojnë, dhe instaluesi i tij zakonisht e vendos atë drejtori pranë fillimit të PATH të përdoruesit.

GnuPG instalohet në drejtorinë e vet, zakonisht C:\Program Files (x86)\GNU\GnuPG\pub, dhe ajo hyrje mund të jetë më poshtë në listë ose të mungojë plotësisht nga PATH i përdoruesit. Dy programet ndajnë një emër dhe një pjesë të madhe të një ndërfaqeje të linjës së komandës, por jo gjendjen e tyre: ndërtimi i Git kërkon një unazë çelësash diku tjetër, mund të jetë version tjetër dhe mund të mos i pranojë opsionet që kalon instaluesi. Kjo mospërputhje shfaqet si gabim nënshkrimi ose çelësi, që është një raport i vërtetë për atë që pa binari i gabuar. Asgjë në mesazh nuk tregon ngarkuesin, sepse ngarkuesi bëri saktësisht atë që iu tha.

Pse shell-i nga i cili filloni vendos rezultatin

Rregulli i trashëgimisë është pjesa që ia vlen të përvetësohet. Një proces fëmijë merr mjedisin e shell-it që e nisi, kështu që rendi që ka rëndësi është rendi në momentin kur Chocolatey nis, jo rendi pasi ta rregulloni.

Kjo është arsyeja pse redaktimi i PATH në një dritare cilësimesh dhe riekzekutimi i instalimit në të njëjtin terminal shpesh nuk ndryshon asgjë: terminali mbajti mjedisin e vjetër. Nisni një shell të re pas çdo ndryshimi dhe konfirmoni me where.exe gpg në atë shell të re përpara se të provoni përsëri. Kjo është edhe arsyeja pse një hyrje në nivel makine mund të mundë një ndryshim në nivel përdoruesi, pasi disa instalues shtojnë në fillim të PATH të makinës dhe hyrjet e makinës vlerësohen përpara hyrjeve të përdoruesit. Nëse të dy nivelet përmbajnë një shteg GnuPG, vendosni cilin po mirëmbani në të vërtetë.

Rregullimi i parë: rirenditni hyrjet

Rregullimi i saktë është të fitojë drejtoria e synuar e GnuPG. Hapni variablat e mjedisit për përdoruesin, redaktoni Path dhe zhvendosni drejtorinë pub të GnuPG mbi hyrjet e Git. Pastaj hapni një dritare të re PowerShell, sepse ajo që po ekzekutohet ende mban listën e vjetër.

Alternativa është një mjedis i pastër i përkohshëm për instalimin: hiqni hyrjet e Git, hapni një shell të re, ekzekutoni choco install openvpn dhe pastaj rikthejini ato.

Të dyja qasjet funksionojnë për të njëjtën arsye, dhe e dyta është e sigurt vetëm nëse i riktheni vërtet hyrjet. Heqja e usr/bin të Git nga PATH prish përgjithmonë commit-et e nënshkruara, dhe mjeti i ardhshëm që pret një gpg funksional dështon me mesazhin e tij që nuk ka asnjë lidhje me OpenVPN. Nëse merrni rrugën e përkohshme, mbani vlerën origjinale të Path në tiketë që rikthimi të jetë ngjitje dhe jo rindërtim. Rregullimi i hyrjeve është rregullimi i qëndrueshëm; fshirja e tyre është një zgjidhje e përkohshme me datë skadimi.

Verifikoni dhe pastaj kthejeni mbrapsht

Verifikoni para dhe pas në të njëjtin kontekst përdoruesi që do të përdorë Chocolatey. where.exe gpg liston çdo përputhje sipas rendit të zgjidhjes, kështu që rreshti i parë është ai që do të ekzekutohet; Get-Command gpg -All jep të njëjtën përgjigje me më shumë detaje në PowerShell. Pastaj gpg --version konfirmon cili ndërtim u përgjigj.

Nëse where.exe ende liston kopjen e Git e para, rirenditja nuk e ka arritur atë sesion, dhe asnjë riinstalim nuk do të ndihmojë. Kontrolloni PATH e makinës dhe të përdoruesit me [Environment]::GetEnvironmentVariable('Path','Machine') dhe të njëjtën thirrje me 'User', sepse lista efektive përbëhet nga të dyja. Pas një instalimi të suksesshëm, rikontrolloni me openvpn --version dhe nisni shërbimin ose GUI një herë, pasi një paketë mund të instalohet pastër dhe të lërë një shërbim që nuk do të niset.

Nëse një PATH i renditur saktë ende dështon, variabla e mbetur është versioni i paketës. Një paketë Chocolatey e fiksuar mund të presë një ndërtim GnuPG ose një shteg instalimi të caktuar që makina juaj nuk e ka.

Lexoni regjistrin e vetë paketës përpara se të ndryshoni çdo gjë tjetër. C:\ProgramData\chocolatey\logs\chocolatey.log regjistron linjën e komandës që dështoi dhe drejtorinë nga e cila u ekzekutua, çka ju tregon nëse thirrja e dështuar ishte kontroll nënshkrimi, nxjerrje ose skript pas instalimit. Ai dallim vendos nëse po korrigjoni ende fare gpg.

Zakoni që parandalon përsëritjen është ta trajtoni PATH si gjendje të përbashkët me një rend të dokumentuar dhe jo si një thes me drejtori. Kur instaloni një mjet që sjell një emër binar të zakonshëm, kontrolloni çfarë hijeshon në shell-in e ardhshëm që hapni. Pastaj shkruani rendin ku u ndalet, sepse instaluesi i ardhshëm do të shtojë në të dhe personi i ardhshëm do të pyesë veten pse një kontroll nënshkrimi dështon në një makinë ku asgjë nuk ka ndryshuar. Një where.exe para instalimit kursen të gjithë ciklin.