Az OpenVPN telepítése meghiúsul, mert a Git gpg-je nyer a PATH-on

Egy OpenVPN-telepítés, amely a Chocolatey alatt aláírás- vagy kulcshibával hal meg, általában nem letöltési probléma. A csomag egy ellenőrzési lépést futtat, amely meghívja a gpg parancsot, és a Windows ezt a csupasz nevet a PATH segítségével oldja fel. Ha a Git for Windows települt előbb, a mellékelt gpg.exe az OpenVPN által várt GnuPG-összeállítás elé kerül, és a rossz program válaszol a hívásra. A látott hiba az, amiről a másik program panaszt tenni döntött, ezért soha nem említi a valódi okot.

A PATH sorrendje dönti el, melyik gpg fut

A Windowsnak nincs központi nyilvántartása a futtatható nevekről. Amikor egy folyamat teljes útvonal nélkül kér gpg-t, a betöltő sorrendben végigjárja a PATH bejegyzéseit, és az első egyezést futtatja. A Git for Windows egy minimális GnuPG-összeállítást szállít a usr/bin könyvtárában, hogy az aláírt commitok működjenek, és a telepítője ezt a könyvtárat általában a felhasználó PATH listájának eleje közelébe helyezi.

A GnuPG a saját könyvtárába települ, általában C:\Program Files (x86)\GNU\GnuPG\pub alá, és ez a bejegyzés lehet később a listán, vagy teljesen hiányozhat a felhasználó PATH listájából. A két program osztozik a néven és a parancssori felület nagy részén, de nem az állapotukon: a Git-összeállítás máshol keres kulcskarikát, lehet más verzió, és előfordulhat, hogy nem fogadja el a telepítő által átadott kapcsolókat. Ez az eltérés aláírás- vagy kulcshibaként jelenik meg, ami valósághű jelentés arról, mit látott a rossz bináris. A hibaüzenetben semmi sem mutat a betöltőre, mert a betöltő pontosan azt tette, amit mondtak neki.

Miért dönti el az eredményt a héj, amelyből indít

Az öröklési szabály az a rész, amit érdemes belsővé tenni. A gyermekfolyamat annak a héjnak a környezetét kapja, amely elindította, tehát a számító sorrend a Chocolatey indulásának pillanatában érvényes sorrend, nem a javítás utáni.

Ezért nem változtat gyakran semmit a PATH szerkesztése egy beállítási ablakban és a telepítés újrafuttatása ugyanabban a terminálban: a terminál megtartotta a régi környezetet. Minden módosítás után indítson új héjat, és az újrapróbálkozás előtt erősítse meg where.exe gpg-vel abban az új héjban. Ez az oka annak is, hogy egy gép szintű bejegyzés felülbírálhat egy felhasználói szintű változtatást, mivel egyes telepítők a gép PATH listájának elejére szúrnak be, és a gép bejegyzéseit a felhasználói bejegyzések előtt értékelik. Ha mindkét szinten van GnuPG-útvonal, döntse el, melyiket gondozza valójában.

Első javítás: rendezze át a bejegyzéseket

A pontos javítás az, hogy a kívánt GnuPG-könyvtár nyerjen. Nyissa meg a felhasználó környezeti változóit, szerkessze a Path bejegyzést, és mozgassa a GnuPG pub könyvtárát a Git-bejegyzések fölé. Ezután nyisson új PowerShell-ablakot, mert a futó még mindig a régi listát tartja.

A másik lehetőség egy ideiglenes tiszta környezet a telepítéshez: távolítsa el a Git-bejegyzéseket, nyisson új héjat, futtassa a choco install openvpn parancsot, majd állítsa vissza őket.

Mindkét megközelítés ugyanazon okból működik, és a második csak akkor biztonságos, ha tényleg visszaállítja a bejegyzéseket. A Git usr/bin könyvtárának eltávolítása a PATH listájáról véglegesen megtöri az aláírt commitokat, és a következő, működő gpg parancsot váró eszköz a saját üzenetével hiúsul meg, amelynek semmi köze az OpenVPN-hez. Ha az ideiglenes utat választja, őrizze meg a Path eredeti értékét a jegyben, hogy a visszaállítás beillesztés legyen, ne újraépítés. A bejegyzések rendezése a tartós javítás; törlésük határidős kerülő megoldás.

Ellenőrizze, majd tegye vissza

Ellenőrizze előtte és utána ugyanabban a felhasználói környezetben, amelyet a Chocolatey használni fog. A where.exe gpg minden egyezést feloldási sorrendben listáz, tehát az első sor az, amely futni fog; a Get-Command gpg -All ugyanazt a választ adja több részlettel a PowerShellben. Ezután a gpg --version megerősíti, melyik összeállítás válaszolt.

Ha a where.exe továbbra is a Git-példányt listázza elsőként, az átrendezés nem érte el azt a munkamenetet, és semmilyen újratelepítés nem segít. Ellenőrizze a gép és a felhasználó PATH listáját is a [Environment]::GetEnvironmentVariable('Path','Machine') paranccsal, és ugyanezt a hívást a 'User' értékkel, mert a tényleges lista mindkettőből áll össze. Sikeres telepítés után ellenőrizze újra a openvpn --version paranccsal, és indítsa el egyszer a szolgáltatást vagy a GUI-t, mert egy csomag tisztán települhet, és mégis olyan szolgáltatást hagyhat, amely nem indul el.

Ha egy helyesen rendezett PATH továbbra is meghiúsul, a fennmaradó változó a csomag verziója. Egy rögzített Chocolatey-csomag olyan GnuPG-összeállítást vagy telepítési útvonalat várhat, amely a gépén nincs.

Olvassa el a csomag saját naplóját, mielőtt bármi mást módosítana. A C:\ProgramData\chocolatey\logs\chocolatey.log rögzíti a meghiúsult parancssort és a könyvtárat, ahonnan futott, ami megmondja, hogy a sikertelen hívás aláírás-ellenőrzés, kibontás vagy telepítés utáni szkript volt-e. Ez a különbségtétel dönti el, hogy egyáltalán még a gpg hibakeresését végzi-e.

Az ismétlődést megelőző szokás, hogy a PATH bejegyzést dokumentált sorrendű megosztott állapotként kezelje, nem könyvtárak zsákjaként. Amikor olyan eszközt telepít, amely gyakori bináris nevet hoz, ellenőrizze, mit árnyékol be a következő megnyitott héjban. Ezután írja le a sorrendet, amelyre jutott, mert a következő telepítő hozzáfűz, és a következő ember azon fog gondolkodni, miért hiúsul meg egy aláírás-ellenőrzés egy gépen, ahol semmi sem változott. Egyetlen where.exe a telepítés előtt megspórolja az egész ciklust.