OpenVPN کی تنصیب ناکام ہوتی ہے کیونکہ Git کا gpg PATH پر جیت جاتا ہے

Chocolatey کے تحت دستخط یا کلید کی خرابی سے مرنے والی OpenVPN تنصیب عام طور پر ڈاؤن لوڈ کا مسئلہ نہیں ہوتی۔ پیکیج ایک تصدیقی مرحلہ چلاتا ہے جو gpg کو کال کرتا ہے، اور Windows اُس ننگے نام کو PATH کے ذریعے حل کرتا ہے۔ اگر Git for Windows پہلے نصب ہوا تھا، تو اُس کا ہمراہ gpg.exe اُس GnuPG بلڈ سے آگے بیٹھتا ہے جس کی OpenVPN توقع کرتا ہے، اور غلط پروگرام کال کا جواب دیتا ہے۔ جو خرابی آپ دیکھتے ہیں وہ وہی ہے جس پر اُس دوسرے پروگرام نے شکایت کرنے کا فیصلہ کیا، اسی لیے یہ کبھی اصل وجہ نہیں بتاتی۔

PATH کی ترتیب طے کرتی ہے کون سا gpg چلے گا

Windows کے پاس قابلِ عمل ناموں کا کوئی مرکزی رجسٹر نہیں ہے۔ جب کوئی عمل مکمل راستے کے بغیر gpg مانگتا ہے، لوڈر PATH کے اندراجات کو ترتیب سے گزرتا ہے اور پہلا مماثل چلاتا ہے۔ Git for Windows دستخط شدہ کمیٹس کے کام کرنے کے لیے اپنی usr/bin ڈائریکٹری میں کم سے کم GnuPG بلڈ لاتا ہے، اور اُس کا انسٹالر عام طور پر وہ ڈائریکٹری صارف کے PATH کے شروع کے قریب رکھتا ہے۔

GnuPG اپنی الگ ڈائریکٹری میں نصب ہوتا ہے، عام طور پر C:\Program Files (x86)\GNU\GnuPG\pub، اور یہ اندراج فہرست میں بعد میں ہو سکتا ہے یا صارف کے PATH سے بالکل غائب ہو سکتا ہے۔ دونوں پروگرام نام اور کمانڈ لائن انٹرفیس کا بڑا حصہ بانٹتے ہیں، مگر اپنی حالت نہیں: Git کا بلڈ کلیدی حلقہ کہیں اور تلاش کرتا ہے، مختلف ورژن ہو سکتا ہے، اور انسٹالر کے بھیجے ہوئے اختیارات قبول نہ کر سکے۔ یہ عدم مطابقت دستخط یا کلید کی خرابی کے طور پر ظاہر ہوتی ہے، جو غلط بائنری نے جو دیکھا اُس کی سچی رپورٹ ہے۔ پیغام میں کوئی چیز لوڈر کی طرف اشارہ نہیں کرتی، کیونکہ لوڈر نے بالکل وہی کیا جو اُسے کہا گیا تھا۔

آپ جس شیل سے شروع کرتے ہیں وہ نتیجہ کیوں طے کرتا ہے

وراثت کا قاعدہ وہ حصہ ہے جسے سمجھ لینا قابلِ قدر ہے۔ چائلڈ عمل اُس شیل کا ماحول پاتا ہے جس نے اُسے شروع کیا، سو اہم ترتیب Chocolatey کے شروع ہونے کے لمحے کی ترتیب ہے، آپ کی اصلاح کے بعد کی ترتیب نہیں۔

اسی لیے سیٹنگز کی کھڑکی میں PATH میں ترمیم کر کے اُسی ٹرمینل میں تنصیب دوبارہ چلانا اکثر کچھ نہیں بدلتا: ٹرمینل نے پرانا ماحول رکھ لیا تھا۔ کسی بھی تبدیلی کے بعد نیا شیل شروع کریں، اور دوبارہ کوشش سے پہلے اُس نئے شیل میں where.exe gpg سے تصدیق کریں۔ یہی وجہ ہے کہ مشین کی سطح کا اندراج صارف کی سطح کی تبدیلی کو ہرا سکتا ہے، کیونکہ کچھ انسٹالر مشین کے PATH کے شروع میں اضافہ کرتے ہیں اور مشین کے اندراجات صارف کے اندراجات سے پہلے جانچے جاتے ہیں۔ اگر دونوں سطحوں میں GnuPG راستہ ہو، تو طے کریں کہ آپ واقعی کس کی دیکھ بھال کر رہے ہیں۔

پہلی اصلاح: اندراجات کی ترتیب بدلیں

درست اصلاح یہ ہے کہ مطلوبہ GnuPG ڈائریکٹری جیت جائے۔ صارف کے ماحولی متغیرات کھولیں، Path میں ترمیم کریں، اور GnuPG کی pub ڈائریکٹری کو Git کے اندراجات سے اوپر منتقل کریں۔ پھر نئی PowerShell کھڑکی کھولیں، کیونکہ چلتی ہوئی کھڑکی ابھی بھی پرانی فہرست تھامے ہوئے ہے۔

متبادل تنصیب کے لیے عارضی صاف ماحول ہے: Git کے اندراجات ہٹائیں، نیا شیل کھولیں، choco install openvpn چلائیں، پھر اُنہیں بحال کریں۔

دونوں طریقے ایک ہی وجہ سے کام کرتے ہیں، اور دوسرا تبھی محفوظ ہے جب آپ واقعی اندراجات بحال کریں۔ Git کی usr/bin کو 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 پورا چکر بچا لیتا ہے۔