OpenVPN ইনস্টল ব্যর্থ হয় কারণ Git-এর gpg PATH-এ জিতে যায়

Chocolatey-র অধীনে স্বাক্ষর বা কী ত্রুটিতে মরে যাওয়া OpenVPN ইনস্টল সাধারণত ডাউনলোডের সমস্যা নয়। প্যাকেজটি একটি যাচাই ধাপ চালায় যা gpg ডাকে, আর Windows সেই খালি নামটি PATH দিয়ে সমাধান করে। যদি Git for Windows আগে ইনস্টল হয়ে থাকে, তবে তার সঙ্গে আসা gpg.exe OpenVPN যে GnuPG বিল্ড আশা করে তার আগে বসে, এবং ভুল প্রোগ্রামটিই ডাকে সাড়া দেয়। আপনি যে ত্রুটি দেখেন সেটি হলো সেই অন্য প্রোগ্রামটি যা নিয়ে অভিযোগ করার সিদ্ধান্ত নিয়েছে, তাই এতে আসল কারণ কখনোই উল্লেখ থাকে না।

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 পুরো লুপটি বাঁচায়।