Instalarea OpenVPN eșuează pentru că gpg-ul Git câștigă în PATH

O instalare OpenVPN care moare sub Chocolatey cu o eroare de semnătură sau de cheie nu este de obicei o problemă de descărcare. Pachetul rulează un pas de verificare care invocă gpg, iar Windows rezolvă acel nume gol prin PATH. Dacă Git for Windows a fost instalat primul, gpg.exe-ul său inclus stă în fața buildului GnuPG pe care îl așteaptă OpenVPN, iar programul greșit răspunde la apel. Eroarea pe care o vedeți este ceea de ce s-a hotărât să se plângă celălalt program, de aceea nu menționează niciodată cauza reală.

Ordinea din PATH decide care gpg rulează

Windows nu are un registru central al numelor de executabile. Când un proces cere gpg fără o cale completă, loaderul parcurge intrările din PATH în ordine și rulează prima potrivire. Git for Windows furnizează un build GnuPG minimal în directorul său usr/bin pentru ca commiturile semnate să funcționeze, iar instalatorul său plasează de obicei acel director aproape de începutul PATH utilizatorului.

GnuPG se instalează în propriul director, de obicei C:\Program Files (x86)\GNU\GnuPG\pub, iar acea intrare poate fi mai jos în listă sau poate lipsi complet din PATH utilizatorului. Cele două programe împart un nume și o mare parte dintr-o interfață de linie de comandă, dar nu și starea lor: buildul Git caută un breloc în altă parte, poate fi o versiune diferită și poate să nu accepte opțiunile pe care le transmite instalatorul. Această nepotrivire se manifestă ca eroare de semnătură sau de cheie, ceea ce este un raport veridic despre ce a văzut binarul greșit. Nimic din mesaj nu indică loaderul, pentru că loaderul a făcut exact ce i s-a spus.

De ce shellul din care porniți decide rezultatul

Regula moștenirii este partea care merită interiorizată. Un proces copil primește mediul shellului care l-a lansat, așa că ordinea care contează este cea din momentul în care pornește Chocolatey, nu cea de după ce o corectați.

De aceea editarea PATH într-o fereastră de setări și rularea din nou a instalării în același terminal nu schimbă adesea nimic: terminalul a păstrat mediul vechi. Porniți un shell nou după orice modificare și confirmați cu where.exe gpg în acel shell nou înainte de a încerca din nou. Tot de aceea o intrare la nivel de mașină poate învinge o modificare la nivel de utilizator, deoarece unii instalatori adaugă la începutul PATH al mașinii, iar intrările de mașină sunt evaluate înaintea celor de utilizator. Dacă ambele niveluri conțin o cale GnuPG, decideți pe care o întrețineți de fapt.

Prima corecție: reordonați intrările

Corecția precisă este să câștige directorul GnuPG dorit. Deschideți variabilele de mediu pentru utilizator, editați Path și mutați directorul pub GnuPG deasupra intrărilor Git. Apoi deschideți o fereastră PowerShell nouă, pentru că cea care rulează încă ține lista veche.

Alternativa este un mediu curat temporar pentru instalare: eliminați intrările Git, deschideți un shell nou, rulați choco install openvpn și apoi le restaurați.

Ambele abordări funcționează din același motiv, iar a doua este sigură doar dacă restaurați efectiv intrările. Eliminarea usr/bin-ului Git din PATH rupe definitiv commiturile semnate, iar următorul instrument care așteaptă un gpg funcțional eșuează cu propriul său mesaj care nu are nimic de-a face cu OpenVPN. Dacă urmați calea temporară, păstrați valoarea originală a Path în tichet pentru ca restaurarea să fie o lipire și nu o reconstrucție. Ordonarea intrărilor este corecția durabilă; ștergerea lor este o soluție temporară cu termen de valabilitate.

Verificați, apoi puneți la loc

Verificați înainte și după în același context de utilizator pe care îl va folosi Chocolatey. where.exe gpg listează fiecare potrivire în ordinea rezolvării, deci prima linie este cea care va rula; Get-Command gpg -All dă același răspuns cu mai multe detalii în PowerShell. Apoi gpg --version confirmă care build a răspuns.

Dacă where.exe încă listează prima copia Git, reordonarea nu a ajuns la acea sesiune, iar nicio reinstalare nu va ajuta. Verificați atât PATH mașinii, cât și al utilizatorului cu [Environment]::GetEnvironmentVariable('Path','Machine') și același apel cu 'User', pentru că lista efectivă este compusă din ambele. După o instalare reușită, verificați din nou cu openvpn --version și porniți o dată serviciul sau GUI-ul, fiindcă un pachet se poate instala curat și totuși poate lăsa un serviciu care nu va porni.

Dacă un PATH ordonat corect încă eșuează, variabila rămasă este versiunea pachetului. Un pachet Chocolatey fixat poate aștepta un build GnuPG sau o cale de instalare anume pe care mașina dumneavoastră nu le are.

Citiți jurnalul propriu al pachetului înainte de a schimba orice altceva. C:\ProgramData\chocolatey\logs\chocolatey.log înregistrează linia de comandă care a eșuat și directorul din care a fost rulată, ceea ce vă spune dacă apelul eșuat a fost o verificare de semnătură, o extragere sau un script după instalare. Această distincție decide dacă mai depanați deloc gpg.

Obiceiul care previne o repetare este să tratați PATH ca stare partajată cu o ordine documentată, nu ca un sac de directoare. Când instalați un instrument care aduce un nume de binar comun, verificați ce umbrește în următorul shell pe care îl deschideți. Apoi notați ordinea la care ați ajuns, pentru că următorul instalator va adăuga la ea, iar următoarea persoană se va întreba de ce o verificare de semnătură eșuează pe o mașină unde nimic nu s-a schimbat. Un singur where.exe înainte de instalare economisește tot ciclul.