نصب OpenVPN شکست می‌خورد چون gpg گیت در PATH پیروز می‌شود

نصب OpenVPN که زیر Chocolatey با خطای امضا یا کلید از کار می‌افتد معمولاً مشکل دانلود نیست. بسته مرحلهٔ بررسی‌ای اجرا می‌کند که gpg را فراخوانی می‌کند و ویندوز آن نام لخت را از طریق PATH حل می‌کند. اگر Git for Windows اول نصب شده باشد، gpg.exe همراه آن جلوتر از نسخهٔ GnuPG که OpenVPN انتظار دارد قرار می‌گیرد و برنامهٔ اشتباه به فراخوانی پاسخ می‌دهد. خطایی که می‌بینید همان چیزی است که آن برنامهٔ دیگر تصمیم گرفته از آن شکایت کند، و به همین دلیل هرگز به علت واقعی اشاره نمی‌کند.

ترتیب PATH تعیین می‌کند کدام gpg اجرا شود

ویندوز هیچ دفتر مرکزی برای نام فایل‌های اجرایی ندارد. وقتی فرایندی gpg را بدون مسیر کامل درخواست می‌کند، بارگذار مدخل‌های PATH را به ترتیب طی می‌کند و اولین تطابق را اجرا می‌کند. Git for Windows نسخهٔ حداقلی GnuPG را درون پوشهٔ usr/bin خود می‌آورد تا کامیت‌های امضاشده کار کنند، و نصب‌کنندهٔ آن معمولاً آن پوشه را نزدیک ابتدای PATH کاربر قرار می‌دهد.

GnuPG در پوشهٔ خودش نصب می‌شود، معمولاً C:\Program Files (x86)\GNU\GnuPG\pub، و آن مدخل ممکن است پایین‌تر در فهرست باشد یا کاملاً از PATH کاربر غایب باشد. این دو برنامه یک نام و بخش بزرگی از سطح خط فرمان را شریک‌اند اما نه وضعیتشان را: نسخهٔ گیت جای دیگری دنبال دسته‌کلید می‌گردد، ممکن است نسخهٔ دیگری باشد و شاید گزینه‌هایی را که نصب‌کننده می‌فرستد نپذیرد. این ناسازگاری به‌صورت خطای امضا یا کلید بروز می‌کند که گزارش صادقانه‌ای از آن چیزی است که فایل اجرایی اشتباه دیده است. هیچ‌چیز در پیام به بارگذار اشاره نمی‌کند، چون بارگذار دقیقاً همان کاری را کرد که به او گفته شده بود.

چرا پوستهٔ شروع شما نتیجه را تعیین می‌کند

قاعدهٔ وراثت بخشی است که ارزش درونی‌سازی دارد. فرایند فرزند محیط پوسته‌ای را می‌گیرد که آن را راه انداخته است، پس ترتیبی که اهمیت دارد ترتیب لحظهٔ شروع Chocolatey است، نه ترتیب پس از اصلاح شما.

به همین دلیل ویرایش PATH در پنجرهٔ تنظیمات و اجرای دوبارهٔ نصب در همان ترمینال اغلب هیچ چیز را تغییر نمی‌دهد: ترمینال محیط قدیمی را نگه داشته است. پس از هر تغییر یک پوستهٔ جدید شروع کنید و پیش از تلاش دوباره با where.exe gpg در همان پوستهٔ جدید تأیید بگیرید. به همین دلیل هم یک مدخل در سطح ماشین می‌تواند تغییر سطح کاربر را شکست دهد، چون بعضی نصب‌کننده‌ها به ابتدای PATH ماشین اضافه می‌کنند و مدخل‌های ماشین پیش از مدخل‌های کاربر ارزیابی می‌شوند. اگر هر دو سطح مسیری از GnuPG دارند، تصمیم بگیرید کدام را واقعاً نگهداری می‌کنید.

اصلاح اول: مدخل‌ها را دوباره مرتب کنید

اصلاح دقیق این است که پوشهٔ موردنظر GnuPG پیروز شود. متغیرهای محیطی کاربر را باز کنید، Path را ویرایش کنید و پوشهٔ pub مربوط به GnuPG را بالای مدخل‌های گیت ببرید. سپس یک پنجرهٔ PowerShell تازه باز کنید، چون پنجرهٔ در حال اجرا هنوز فهرست قدیمی را نگه داشته است.

جایگزین، یک محیط تمیز موقت برای نصب است: مدخل‌های گیت را بردارید، پوستهٔ جدید باز کنید، choco install openvpn را اجرا کنید و سپس آن‌ها را برگردانید.

هر دو رویکرد به یک دلیل کار می‌کنند و دومی فقط وقتی ایمن است که واقعاً مدخل‌ها را برگردانید. حذف usr/bin گیت از PATH کامیت‌های امضاشده را برای همیشه می‌شکند و ابزار بعدی که gpg سالم انتظار دارد با پیام خودش شکست می‌خورد که هیچ ارتباطی با OpenVPN ندارد. اگر مسیر موقت را برمی‌گزینید، مقدار اصلی Path را در تیکت نگه دارید تا بازگردانی یک چسباندن باشد نه بازسازی. مرتب‌کردن مدخل‌ها اصلاح پایدار است؛ حذف آن‌ها راه‌حلی موقت با تاریخ انقضاست.

بررسی کنید، سپس برگردانید

پیش و پس در همان زمینهٔ کاربری‌ای که Chocolatey استفاده خواهد کرد بررسی کنید. where.exe gpg هر تطابق را به ترتیب حل فهرست می‌کند، پس خط اول همانی است که اجرا می‌شود؛ Get-Command gpg -All در PowerShell همان پاسخ را با جزئیات بیشتر می‌دهد. سپس gpg --version تأیید می‌کند کدام نسخه پاسخ داده است.

اگر where.exe هنوز نسخهٔ گیت را اول فهرست می‌کند، تغییر ترتیب به آن نشست نرسیده است و هیچ نصب دوباره‌ای کمکی نمی‌کند. PATH ماشین و کاربر را با [Environment]::GetEnvironmentVariable('Path','Machine') و همان فراخوانی با 'User' بررسی کنید، چون فهرست مؤثر از هر دو ساخته می‌شود. پس از نصب موفق، با openvpn --version دوباره بررسی کنید و سرویس یا GUI را یک بار راه بیندازید، چون بسته ممکن است تمیز نصب شود و با این حال سرویسی بگذارد که راه نمی‌افتد.

اگر PATH درست مرتب‌شده هنوز شکست می‌خورد، متغیر باقی‌مانده نسخهٔ بسته است. بستهٔ پین‌شدهٔ Chocolatey ممکن است نسخهٔ مشخصی از GnuPG یا مسیر نصبی انتظار داشته باشد که ماشین شما ندارد.

گزارش خود بسته را بخوانید پیش از تغییر هر چیز دیگری. C:\ProgramData\chocolatey\logs\chocolatey.log خط فرمانی که شکست خورده و پوشه‌ای که از آن اجرا شده را ثبت می‌کند، که به شما می‌گوید فراخوانی ناموفق بررسی امضا، استخراج یا اسکریپت پس از نصب بوده است. همین تمایز تعیین می‌کند که آیا هنوز اصلاً gpg را اشکال‌زدایی می‌کنید.

عادتی که از تکرار جلوگیری می‌کند این است که با PATH به‌عنوان وضعیت مشترک با ترتیبی مستند رفتار کنید، نه به‌عنوان کیسه‌ای از پوشه‌ها. وقتی ابزاری نصب می‌کنید که یک نام اجرایی رایج را همراه دارد، بررسی کنید در پوستهٔ بعدی که باز می‌کنید چه چیزی را سایه می‌اندازد. سپس ترتیبی را که بر آن مستقر شدید بنویسید، چون نصب‌کنندهٔ بعدی به آن اضافه خواهد کرد و نفر بعدی تعجب می‌کند چرا بررسی امضا روی ماشینی که هیچ چیز تغییر نکرده شکست می‌خورد. یک where.exe پیش از نصب کل حلقه را ذخیره می‌کند.