Usakinishaji wa OpenVPN unashindwa kwa sababu gpg ya Git inashinda kwenye PATH

Usakinishaji wa OpenVPN unaokufa chini ya Chocolatey kwa hitilafu ya saini au ufunguo kwa kawaida si tatizo la upakuaji. Kifurushi huendesha hatua ya uthibitishaji inayoiita gpg, na Windows hutatua jina hilo tupu kupitia PATH. Ikiwa Git for Windows ilisakinishwa kwanza, gpg.exe yake iliyoambatanishwa inasimama mbele ya muundo wa GnuPG ambao OpenVPN inatarajia, na programu isiyo sahihi hujibu mwito huo. Hitilafu unayoona ni kile ambacho programu ile nyingine iliamua kulalamika juu yake, ndiyo sababu kamwe haitaji sababu halisi.

Mpangilio wa PATH huamua gpg ipi inaendeshwa

Windows haina rejista kuu ya majina ya vitekelezo. Mchakato unapoomba gpg bila njia kamili, kipakiaji hupitia maingizo ya PATH kwa mpangilio na kuendesha mechi ya kwanza. Git for Windows hutoa muundo mdogo wa GnuPG ndani ya saraka yake usr/bin ili commits zilizosainiwa zifanye kazi, na kisakinishi chake kwa kawaida huweka saraka hiyo karibu na mwanzo wa PATH ya mtumiaji.

GnuPG hujisakinisha katika saraka yake mwenyewe, kwa kawaida C:\Program Files (x86)\GNU\GnuPG\pub, na ingizo hilo linaweza kuwa baadaye kwenye orodha au likose kabisa kutoka PATH ya mtumiaji. Programu mbili hushiriki jina na sehemu kubwa ya kiolesura cha mstari wa amri lakini si hali yao: muundo wa Git hutafuta pete ya funguo mahali pengine, unaweza kuwa toleo tofauti, na unaweza usikubali chaguo ambazo kisakinishi hupitisha. Tofauti hiyo hujitokeza kama hitilafu ya saini au ufunguo, ambayo ni ripoti ya kweli ya kile ambacho faili binary isiyo sahihi iliona. Hakuna chochote katika ujumbe kinachoelekeza kwa kipakiaji, kwa sababu kipakiaji kilifanya hasa kile kilichoambiwa.

Kwa nini shell unayoanzia huamua matokeo

Kanuni ya urithi ni sehemu inayostahili kuingizwa ndani. Mchakato mtoto hupata mazingira ya shell iliyouanzisha, kwa hivyo mpangilio unaojali ni mpangilio wakati Chocolatey inapoanza, sio mpangilio baada ya wewe kuirekebisha.

Ndiyo sababu kuhariri PATH kwenye dirisha la mipangilio na kuendesha usakinishaji tena katika terminal ile ile mara nyingi hakubadilishi chochote: terminal ilihifadhi mazingira ya zamani. Anzisha shell mpya baada ya kila mabadiliko, na uthibitishe kwa where.exe gpg katika shell hiyo mpya kabla ya kujaribu tena. Ndiyo sababu pia ingizo la ngazi ya mashine linaweza kushinda mabadiliko ya ngazi ya mtumiaji, kwa kuwa baadhi ya visakinishi huongeza mwanzoni mwa PATH ya mashine na maingizo ya mashine hupimwa kabla ya yale ya mtumiaji. Ikiwa ngazi zote mbili zina njia ya GnuPG, amua ni ipi unayoitunza kweli.

Marekebisho ya kwanza: panga upya maingizo

Marekebisho sahihi ni kufanya saraka inayokusudiwa ya GnuPG ishinde. Fungua vigeu vya mazingira vya mtumiaji, hariri Path, na uhamishe saraka ya pub ya GnuPG juu ya maingizo ya Git. Kisha fungua dirisha jipya la PowerShell, kwa sababu linaloendesha bado linashikilia orodha ya zamani.

Njia mbadala ni mazingira safi ya muda kwa usakinishaji: ondoa maingizo ya Git, fungua shell mpya, endesha choco install openvpn, kisha uyarejeshe.

Njia zote mbili zinafanya kazi kwa sababu moja, na ya pili ni salama tu ikiwa utayarejesha maingizo kweli. Kuondoa usr/bin ya Git kutoka PATH huvunja commits zilizosainiwa kabisa, na chombo kinachofuata kinachotarajia gpg inayofanya kazi hushindwa na ujumbe wake ambao hauna uhusiano wowote na OpenVPN. Ukichagua njia ya muda, hifadhi thamani halisi ya Path kwenye tiketi ili urejeshaji uwe mbandiko na sio ujenzi upya. Kupanga maingizo ni marekebisho ya kudumu; kuyafuta ni suluhisho la muda lenye tarehe ya mwisho.

Thibitisha, kisha urudishe

Thibitisha kabla na baada katika muktadha ule ule wa mtumiaji ambao Chocolatey itatumia. where.exe gpg huorodhesha kila mechi kwa mpangilio wa utatuzi, kwa hivyo mstari wa kwanza ndio utakaoendeshwa; Get-Command gpg -All hutoa jibu lile lile kwa maelezo zaidi katika PowerShell. Kisha gpg --version huthibitisha ni muundo upi ulijibu.

Ikiwa where.exe bado inaorodhesha nakala ya Git kwanza, upangaji upya haujafika kwenye kikao hicho, na usakinishaji upya wa kiasi wowote hautasaidia. Angalia PATH ya mashine na ya mtumiaji kwa [Environment]::GetEnvironmentVariable('Path','Machine') na mwito ule ule kwa 'User', kwa sababu orodha inayofaa huundwa kutoka zote mbili. Baada ya usakinishaji wenye mafanikio, angalia tena kwa openvpn --version na uanzishe huduma au GUI mara moja, kwa kuwa kifurushi kinaweza kusakinishwa safi na bado kiacha huduma ambayo haitaanza.

Ikiwa PATH iliyopangwa vizuri bado inashindwa, kigeu kilichobaki ni toleo la kifurushi. Kifurushi cha Chocolatey kilichobandikwa kinaweza kutarajia muundo maalum wa GnuPG au njia ya usakinishaji ambayo mashine yako haina.

Soma logi ya kifurushi yenyewe kabla ya kubadilisha kitu kingine chochote. C:\ProgramData\chocolatey\logs\chocolatey.log hurekodi mstari wa amri ulioshindwa na saraka uliyoendeshwa kutoka humo, ambayo inakuambia ikiwa mwito ulioshindwa ulikuwa ukaguzi wa saini, uchimbaji au script ya baada ya usakinishaji. Tofauti hiyo huamua ikiwa bado unatatua matatizo ya gpg kabisa.

Tabia inayozuia kurudia ni kuichukulia PATH kama hali inayoshirikiwa yenye mpangilio ulioandikwa badala ya kama mfuko wa saraka. Unaposakinisha chombo kinacholeta jina la kawaida la binary, angalia kinachofunika katika shell inayofuata unayofungua. Kisha andika mpangilio uliokaa nao, kwa sababu kisakinishi kinachofuata kitaongeza kwake na mtu anayefuata atajiuliza kwa nini ukaguzi wa saini unashindwa kwenye mashine ambayo hakuna kilichobadilika. where.exe moja kabla ya usakinishaji huokoa mzunguko mzima.