Встановлення OpenVPN не вдається, бо gpg з Git перемагає в PATH
Git for Windows постачає власний gpg.exe, і порядок у PATH визначає, який із них запустить інсталятор OpenVPN. Перевірте за допомогою where.exe, а потім перевпорядкуйте, а не видаляйте.
Встановлення 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 перед встановленням економить увесь цикл.