Инсталирането на OpenVPN се проваля, защото gpg на Git печели в PATH

Инсталация на OpenVPN, която умира под Chocolatey с грешка за подпис или ключ, обикновено не е проблем с изтеглянето. Пакетът изпълнява стъпка за проверка, която извиква gpg, и Windows разрешава това голо име през PATH. Ако Git for Windows е инсталиран първи, вграденият му gpg.exe стои пред сборката на GnuPG, която OpenVPN очаква, и на повикването отговаря грешната програма. Грешката, която виждате, е това, за което онази друга програма е решила да се оплаче, и затова тя никога не споменава истинската причина.

Редът на PATH решава кой gpg се изпълнява

Windows няма централен регистър на имената на изпълними файлове. Когато процес поиска gpg без пълен път, зареждащият преглежда записите в PATH по ред и стартира първото съвпадение. Git for Windows доставя минимална сборка на GnuPG в своята директория usr/bin, за да работят подписаните комити, и неговият инсталатор обикновено поставя тази директория близо до началото на PATH на потребителя.

GnuPG се инсталира в собствена директория, обикновено C:\Program Files (x86)\GNU\GnuPG\pub, и този запис може да е по-назад в списъка или да липсва изцяло от PATH на потребителя. Двете програми споделят име и голяма част от интерфейса на командния ред, но не и състоянието си: сборката на Git търси ключодържател другаде, може да е различна версия и може да не приема опциите, които инсталаторът подава. Това несъответствие се проявява като грешка за подпис или ключ, което е честен отчет за това, което е видял грешният двоичен файл. Нищо в съобщението не сочи към зареждащия, защото той е направил точно това, което му е било казано.

Защо обвивката, от която стартирате, решава резултата

Правилото за наследяване е частта, която си струва да се осмисли. Дъщерният процес получава средата на обвивката, която го е стартирала, така че редът, който има значение, е редът в момента, в който Chocolatey стартира, а не редът, след като го поправите.

Ето защо редактирането на PATH в прозорец с настройки и повторното пускане на инсталацията в същия терминал често не променя нищо: терминалът е запазил старата среда. Стартирайте нова обвивка след всяка промяна и потвърдете с where.exe gpg в тази нова обвивка, преди да опитате отново. Това също обяснява защо запис на ниво машина може да надделее над промяна на ниво потребител, тъй като някои инсталатори добавят в началото на PATH на машината, а записите на машината се оценяват преди тези на потребителя. Ако и двете нива съдържат път до GnuPG, решете кое от тях всъщност поддържате.

Поправка първа: пренаредете записите

Точната поправка е желаната директория на GnuPG да спечели. Отворете променливите на средата за потребителя, редактирайте Path и преместете директорията pub на GnuPG над записите на Git. След това отворете нов прозорец на PowerShell, защото работещият все още държи стария списък.

Алтернативата е временна чиста среда за инсталацията: премахнете записите на Git, отворете нова обвивка, изпълнете choco install openvpn и след това ги възстановете.

И двата подхода работят по една и съща причина, а вторият е безопасен само ако наистина възстановите записите. Премахването на usr/bin на Git от PATH трайно чупи подписаните комити и следващият инструмент, който очаква работещ gpg, се проваля със свое собствено съобщение, което няма нищо общо с OpenVPN. Ако поемете временния път, запазете оригиналната стойност на Path в тикета, за да бъде възстановяването поставяне, а не реконструкция. Подреждането на записите е трайната поправка; изтриването им е заобиколно решение със срок.

Проверете, след което върнете обратно

Проверете преди и след в същия потребителски контекст, който Chocolatey ще използва. where.exe gpg изброява всяко съвпадение в ред на разрешаване, така че първият ред е този, който ще се изпълни; Get-Command gpg -All дава същия отговор с повече подробности в PowerShell. След това gpg --version потвърждава коя сборка е отговорила.

Ако where.exe все още изброява копието на Git първо, пренареждането не е достигнало тази сесия и никакво преинсталиране няма да помогне. Проверете PATH както на машината, така и на потребителя с [Environment]::GetEnvironmentVariable('Path','Machine') и същото извикване с 'User', защото ефективният списък се сглобява от двете. След успешна инсталация проверете отново с openvpn --version и стартирайте услугата или GUI веднъж, тъй като пакетът може да се инсталира чисто и въпреки това да остави услуга, която няма да стартира.

Ако правилно подреден PATH все още се проваля, оставащата променлива е версията на пакета. Фиксиран пакет на Chocolatey може да очаква конкретна сборка на GnuPG или път за инсталация, който вашата машина няма.

Прочетете собствения дневник на пакета, преди да променяте нещо друго. C:\ProgramData\chocolatey\logs\chocolatey.log записва командния ред, който се е провалил, и директорията, от която е стартиран, което ви казва дали неуспешното повикване е проверка на подпис, извличане или скрипт след инсталация. Това разграничение решава дали изобщо все още отстранявате проблеми с gpg.

Навикът, който предотвратява повторение, е да се отнасяте към PATH като към споделено състояние с документиран ред, а не като към торба с директории. Когато инсталирате инструмент, който носи общо име на двоичен файл, проверете какво засенчва той в следващата обвивка, която отворите. След това запишете реда, на който сте се спрели, защото следващият инсталатор ще добави към него и следващият човек ще се чуди защо проверка на подпис се проваля на машина, където нищо не се е променило. Едно where.exe преди инсталацията спестява целия цикъл.