Instalo de OpenVPN malsukcesas ĉar la gpg de Git venkas sur PATH

OpenVPN-instalo, kiu mortas sub Chocolatey kun subskriba aŭ ŝlosila eraro, kutime ne estas elŝuta problemo. La pako rulas kontrolpaŝon, kiu vokas gpg, kaj Windows solvas tiun nudan nomon per PATH. Se Git for Windows estis instalita unue, ĝia kunportita gpg.exe staras antaŭ la GnuPG-konstruo, kiun OpenVPN atendas, kaj la malĝusta programo respondas la vokon. La eraro, kiun vi vidas, estas tio, pri kio tiu alia programo decidis plendi, kaj tial ĝi neniam mencias la veran kaŭzon.

La ordo de PATH decidas, kiu gpg ruliĝas

Windows ne havas centran registron de plenumeblaj nomoj. Kiam procezo petas gpg sen plena vojo, la ŝargilo trairas la erojn de PATH laŭ ordo kaj rulas la unuan kongruon. Git for Windows liveras minimuman GnuPG-konstruon ene de sia usr/bin-dosierujo, por ke subskribitaj kommitoj funkciu, kaj ĝia instalilo kutime metas tiun dosierujon proksime al la komenco de la PATH de la uzanto.

GnuPG instaliĝas en sian propran dosierujon, kutime C:\Program Files (x86)\GNU\GnuPG\pub, kaj tiu ero povas esti pli poste en la listo aŭ tute manki el la PATH de la uzanto. La du programoj dividas nomon kaj grandan parton de komandlinia surfaco, sed ne sian staton: la Git-konstruo serĉas ŝlosilaron aliloke, eble estas alia versio, kaj eble ne akceptas la opciojn, kiujn la instalilo transdonas. Tiu miskongruo aperas kiel subskriba aŭ ŝlosila eraro, kio estas vera raporto pri tio, kion vidis la malĝusta binara dosiero. Nenio en la mesaĝo montras al la ŝargilo, ĉar la ŝargilo faris ĝuste tion, kion oni diris al ĝi.

Kial la ŝelo, de kiu vi startas, decidas la rezulton

La hereda regulo estas la parto inda je internigo. Infana procezo ricevas la medion de la ŝelo, kiu lanĉis ĝin, do la ordo, kiu gravas, estas la ordo en la momento, kiam Chocolatey startas, ne la ordo post kiam vi riparas ĝin.

Tial redakti PATH en agorda fenestro kaj reruli la instalon en la sama terminalo ofte ŝanĝas nenion: la terminalo konservis la malnovan medion. Startu novan ŝelon post ĉiu redakto, kaj konfirmu per where.exe gpg en tiu nova ŝelo antaŭ ol reprovi. Tial ankaŭ maŝinnivela ero povas venki uzantnivelan ŝanĝon, ĉar iuj instaliloj antaŭmetas al la maŝina PATH kaj maŝinaj eroj estas taksataj antaŭ uzantaj eroj. Se ambaŭ niveloj enhavas GnuPG-vojon, decidu, kiun vi efektive prizorgas.

Riparo unu: reordigu la erojn

La preciza riparo estas igi la celatan GnuPG-dosierujon venki. Malfermu la mediajn variablojn por la uzanto, redaktu Path, kaj movu la GnuPG-pub-dosierujon super la Git-erojn. Poste malfermu novan PowerShell-fenestron, ĉar la kuranta ankoraŭ tenas la malnovan liston.

La alternativo estas provizora pura medio por la instalo: forigu la Git-erojn, malfermu novan ŝelon, rulu choco install openvpn, poste restarigu ilin.

Ambaŭ aliroj funkcias pro la sama kialo, kaj la dua estas sekura nur se vi efektive restarigas la erojn. Forigi la usr/bin de Git el PATH permanente rompas subskribitajn kommitojn, kaj la sekva ilo, kiu atendas funkciantan gpg, malsukcesas kun propra mesaĝo, kiu havas nenion komunan kun OpenVPN. Se vi prenas la provizoran vojon, konservu la originan valoron de Path en la bileto, por ke la restarigo estu algluo anstataŭ rekonstruo. Ordigi la erojn estas la daŭra riparo; forigi ilin estas provizora solvo kun limdato.

Kontrolu, poste remetu ĝin

Kontrolu antaŭe kaj poste en la sama uzantkunteksto, kiun Chocolatey uzos. where.exe gpg listigas ĉiun kongruon laŭ solva ordo, do la unua linio estas tiu, kiu ruliĝos; Get-Command gpg -All donas la saman respondon kun pli da detaloj en PowerShell. Poste gpg --version konfirmas, kiu konstruo respondis.

Se where.exe ankoraŭ listigas la Git-kopion unue, la reordigo ne atingis tiun sesion, kaj neniu kvanto da reinstalo helpos. Kontrolu kaj la maŝinan kaj la uzantan PATH per [Environment]::GetEnvironmentVariable('Path','Machine') kaj la sama voko per 'User', ĉar la efektiva listo estas kunmetita el ambaŭ. Post sukcesa instalo, rekontrolu per openvpn --version kaj startu la servon aŭ la GUI unufoje, ĉar pako povas instaliĝi pure kaj tamen lasi servon, kiu ne startos.

Se ĝuste ordigita PATH ankoraŭ malsukcesas, la restanta variablo estas la paka versio. Fiksita Chocolatey-pako eble atendas specifan GnuPG-konstruon aŭ instalvojon, kiun via maŝino ne havas.

Legu la propran protokolon de la pako antaŭ ol ŝanĝi ion alian. C:\ProgramData\chocolatey\logs\chocolatey.log registras la komandlinion, kiu malsukcesis, kaj la dosierujon, el kiu ĝi ruliĝis, kio diras al vi, ĉu la malsukcesa voko estis subskriba kontrolo, eltiro aŭ postinstala skripto. Tiu distingo decidas, ĉu vi entute ankoraŭ sencimigas gpg.

La kutimo, kiu malhelpas ripeton, estas trakti PATH kiel komunan staton kun dokumentita ordo anstataŭ kiel sakon da dosierujoj. Kiam vi instalas ilon, kiu kunportas komunan binaran nomon, kontrolu, kion ĝi ombrumas en la sekva ŝelo, kiun vi malfermas. Poste skribu la ordon, sur kiu vi decidis, ĉar la sekva instalilo aldonos al ĝi kaj la sekva persono demandos sin, kial subskriba kontrolo malsukcesas sur maŝino, kie nenio ŝanĝiĝis. Unu where.exe antaŭ la instalo ŝparas la tutan buklon.