Instalace OpenVPN selhává, protože gpg z Gitu vyhrává na PATH

Instalace OpenVPN, která pod Chocolatey zemře s chybou podpisu nebo klíče, obvykle není problém stahování. Balíček spouští krok ověření, který volá gpg, a Windows toto holé jméno vyřeší přes PATH. Pokud byl Git for Windows nainstalován první, jeho přiložený gpg.exe stojí před sestavením GnuPG, které OpenVPN očekává, a na volání odpovídá špatný program. Chyba, kterou vidíte, je to, na co se ten druhý program rozhodl stěžovat, a proto nikdy neuvádí skutečnou příčinu.

Pořadí PATH rozhoduje, který gpg se spustí

Windows nemá centrální registr názvů spustitelných souborů. Když proces požádá o gpg bez úplné cesty, zavaděč prochází položky PATH v pořadí a spustí první shodu. Git for Windows dodává minimální sestavení GnuPG do svého adresáře usr/bin, aby fungovaly podepsané commity, a jeho instalátor obvykle umístí tento adresář blízko začátku uživatelova PATH.

GnuPG se instaluje do vlastního adresáře, obvykle C:\Program Files (x86)\GNU\GnuPG\pub, a tato položka může být v seznamu později nebo v uživatelově PATH zcela chybět. Oba programy sdílejí jméno a velkou část rozhraní příkazového řádku, ale ne svůj stav: sestavení z Gitu hledá klíčenku jinde, může mít jinou verzi a nemusí přijímat volby, které instalátor předává. Tento nesoulad se projeví jako chyba podpisu nebo klíče, což je pravdivá zpráva o tom, co špatný binární soubor viděl. Nic ve zprávě neukazuje na zavaděč, protože zavaděč udělal přesně to, co mu bylo řečeno.

Proč výsledek určuje shell, ze kterého startujete

Pravidlo dědění je část, kterou stojí za to si osvojit. Podřízený proces dostane prostředí shellu, který jej spustil, takže rozhodující je pořadí v okamžiku, kdy Chocolatey startuje, ne pořadí poté, co ho opravíte.

Proto úprava PATH v okně nastavení a opětovné spuštění instalace ve stejném terminálu často nic nezmění: terminál si ponechal staré prostředí. Po každé úpravě spusťte nový shell a před dalším pokusem to potvrďte pomocí where.exe gpg v tomto novém shellu. To je také důvod, proč položka na úrovni počítače může přebít změnu na úrovni uživatele, protože některé instalátory přidávají na začátek PATH počítače a položky počítače se vyhodnocují před položkami uživatele. Pokud obě úrovně obsahují cestu ke GnuPG, rozhodněte, kterou vlastně udržujete.

Oprava první: změňte pořadí položek

Přesná oprava je přimět zamýšlený adresář GnuPG, aby vyhrál. Otevřete proměnné prostředí pro uživatele, upravte Path a přesuňte adresář pub GnuPG nad položky Gitu. Pak otevřete nové okno PowerShellu, protože to běžící stále drží starý seznam.

Alternativou je dočasné čisté prostředí pro instalaci: odstraňte položky Gitu, otevřete nový shell, spusťte choco install openvpn a poté je obnovte.

Oba přístupy fungují ze stejného důvodu a druhý je bezpečný jen tehdy, když položky skutečně obnovíte. Odstranění Gitova usr/bin z PATH trvale rozbije podepsané commity a další nástroj, který očekává funkční gpg, selže s vlastní zprávou, jež nemá s OpenVPN nic společného. Pokud zvolíte dočasnou cestu, uložte původní hodnotu Path do ticketu, aby obnovení bylo vložením, a ne rekonstrukcí. Uspořádání položek je trvalá oprava; jejich smazání je obejití s termínem.

Ověřte a poté to vraťte zpět

Ověřte před a po ve stejném uživatelském kontextu, který bude Chocolatey používat. where.exe gpg vypisuje každou shodu v pořadí řešení, takže první řádek je ten, který se spustí; Get-Command gpg -All dává v PowerShellu stejnou odpověď s větším množstvím podrobností. Poté gpg --version potvrdí, které sestavení odpovědělo.

Pokud where.exe stále uvádí kopii z Gitu jako první, změna pořadí se do této relace nedostala a žádné přeinstalování nepomůže. Zkontrolujte PATH jak na úrovni počítače, tak uživatele pomocí [Environment]::GetEnvironmentVariable('Path','Machine') a stejného volání s 'User', protože efektivní seznam se skládá z obou. Po úspěšné instalaci znovu zkontrolujte pomocí openvpn --version a jednou spusťte službu nebo GUI, protože balíček se může nainstalovat čistě a přesto zanechat službu, která se nespustí.

Pokud správně seřazený PATH stále selhává, zbývající proměnnou je verze balíčku. Přišpendlený balíček Chocolatey může očekávat konkrétní sestavení GnuPG nebo cestu instalace, kterou váš počítač nemá.

Přečtěte si vlastní log balíčku, než změníte cokoli dalšího. C:\ProgramData\chocolatey\logs\chocolatey.log zaznamenává příkazový řádek, který selhal, a adresář, ze kterého byl spuštěn, což vám řekne, zda neúspěšné volání bylo kontrola podpisu, extrakce nebo skript po instalaci. Toto rozlišení rozhoduje o tom, zda vůbec ještě ladíte gpg.

Návyk, který brání opakování, je považovat PATH za sdílený stav se zdokumentovaným pořadím, nikoli za pytel adresářů. Když instalujete nástroj, který nese běžný název binárky, zkontrolujte, co zastíní v dalším shellu, který otevřete. Poté si zapište pořadí, na kterém jste se ustálili, protože další instalátor k němu přidá a další člověk se bude divit, proč kontrola podpisu selhává na počítači, kde se nic nezměnilo. Jeden where.exe před instalací ušetří celý cyklus.