OpenVPN 3 Python ত্রুটি: সিস্টেমের Python নয়, টুলটিই ঠিক করুন
ট্রেসব্যাক কোন ইন্টারপ্রেটার ফ্রন্টএন্ড চালিয়েছে তা দেখায়, টানেলের মালিক যে সার্ভিস তা নয়। সিস্টেমজুড়ে কিছু বদলানোর আগে দুটির তুলনা করুন।
VPN ব্যবস্থাপনার কোনো কমান্ড শুরু হলে একটি ট্রেসব্যাক দেখা যায়, আর প্রথম প্রবৃত্তি হয় অন্য একটি Python ইনস্টল করা বা সিস্টেমের ডিফল্টকে অন্য জায়গায় নির্দেশ করা। এই প্রবৃত্তি পরস্পরের সঙ্গে কোনো সম্পর্ক নেই এমন দুটি রানটাইম মিশিয়ে ফেলে। একটি অপারেটিং সিস্টেম ও তার প্যাকেজকৃত টুলগুলোর; অন্যটি আপনার তৈরি যে-কোনো প্রকল্পের। দ্বিতীয়টিকে সন্তুষ্ট করতে প্রথমটি বদলানোই সেই পথ যেখানে একটি সচল ডেস্কটপ তার প্যাকেজ ম্যানেজার হারায়।
যে তুলনাটি করা মূল্যবান তা হলো যে উপাদানটি সত্যিই ব্যর্থ হয়েছে এবং যে রানটাইম বদলানোর অধিকার আপনার আছে, এই দুটির মধ্যে। তারা প্রায় কখনোই একই বস্তু নয়।
একটির মতো দেখতে দুটি Python প্রশ্ন
প্রথম প্রশ্ন: কোন ইন্টারপ্রেটার সেই প্রোগ্রামটি চালিয়েছে যা ট্রেসব্যাকটি ছেপেছে? দ্বিতীয়টি: আমার প্রকল্পের কোন ইন্টারপ্রেটার ব্যবহার করা উচিত? টার্মিনালে দুটিই একই দেখায়, কারণ দুটিরই উত্তর দেওয়া হয় python3 টাইপ করে, এবং তাদের মালিক আলাদা, আপগ্রেডের পথ আলাদা ও প্রভাবের পরিধি আলাদা।
একটি সিস্টেম টুল তার ডিস্ট্রিবিউশনের সঙ্গে যে ইন্টারপ্রেটার এসেছিল তার সঙ্গে বাঁধা, এবং সেই ইন্টারপ্রেটারের ABI-র বিপরীতে নির্মিত কম্পাইলকৃত মডিউলগুলোর সঙ্গেও। একটি প্রকল্প বাঁধা তার জন্য আপনার তৈরি যে-কোনো এনভায়রনমেন্টের সঙ্গে। সিস্টেমের ডিফল্ট সরানো একসঙ্গে মেশিনের প্রতিটি টুলের জন্য প্রথমটিকে বদলায়; একটি এনভায়রনমেন্ট তৈরি করা একটি ডিরেক্টরির জন্য দ্বিতীয়টিকে বদলায়।
এই কাজগুলোর মধ্যে কেবল একটি এক মিনিটে ফিরিয়ে আনা যায়। সেটি প্রথমটি নয়।
কোন উপাদান ত্রুটিটি তৈরি করেছে
আর কিছু পড়ার আগে ট্রেসব্যাকের প্রথম লাইন ও যে এক্সিকিউটেবল এটি তৈরি করেছে তা পড়ুন। কমান্ড-লাইন ফ্রন্টএন্ড, বিশেষাধিকারপ্রাপ্ত সার্ভিস ও API বাইন্ডিং আলাদা আলাদা অংশ, এবং তাদের কেবল কিছুই আদৌ Python।
command -v openvpn3
head -n 1 "$(command -v openvpn3)"
dpkg -S "$(command -v openvpn3)" 2>/dev/null
systemctl status openvpn3-service-client --no-pager
স্ক্রিপ্টের প্রথম লাইন কোন ইন্টারপ্রেটার ব্যবহার হবে তা নাম দেয়, এবং ট্রেসব্যাকটি সেই ইন্টারপ্রেটার থেকেই এসেছে। প্যাকেজ কুয়েরি আপনাকে বলে ফাইলটির মালিক কে, যা ঠিক করে কে এটি বদলানোর অনুমতি পাবে। সার্ভিসের অবস্থা সম্পূর্ণ ভিন্ন এক প্রশ্নের উত্তর দেয়: যে বিশেষাধিকারপ্রাপ্ত ব্যাকএন্ড সত্যিই সেশন প্রতিষ্ঠা করে সেটি চলছে কি না।
মডিউল ইমপোর্ট ত্রুটি, D-Bus অ্যাক্টিভেশন প্রত্যাখ্যান এবং প্রত্যাখ্যাত ক্রেডেনশিয়াল তিনটি ভিন্ন পর্যায়। ইমপোর্ট ত্রুটি কোনো সেশন থাকার আগেই ঘটে, তাই কোনো VPN কনফিগারেশনই তা ঠিক করবে না, এবং একটি সচল সার্ভিসও তা ঠিক করবে না। বার্তাটিকে এই তিন পর্যায়ের একটিতে ভাগ করাই প্রকৃত প্রথম ধাপ।
প্রকল্প এনভায়রনমেন্ট কী ঠিক করতে পারে আর কী পারে না
প্রকল্প এনভায়রনমেন্ট একটি প্রকল্পের সমস্যার সমাধান করে: একটি অ্যাপ্লিকেশনের প্রয়োজনীয় নির্দিষ্ট লাইব্রেরি সংস্করণ, বাকি সবকিছু থেকে বিচ্ছিন্ন। এটি সত্যিই কাজে লাগে এবং ব্যর্থ প্রোগ্রামটি যখন আপনার নিজের স্ক্রিপ্ট, তখন এটিই সঠিক টুল।
uv run --python 3.11 app.py
python3 -c 'import openvpn3; print(openvpn3.__file__)'
দ্বিতীয় কমান্ডটি দেখায় একটি নির্দিষ্ট ইন্টারপ্রেটার বাইন্ডিংয়ের কোন অনুলিপি দেখতে পায়, যা অনুপস্থিত প্যাকেজকে ছায়াচ্ছন্ন প্যাকেজ থেকে আলাদা করার দ্রুততম উপায়। এটি ব্যর্থ স্ক্রিপ্ট যে ইন্টারপ্রেটার ব্যবহার করে সেটি দিয়েই চালান, দৈবাৎ কাজ করে এমন অন্য একটি দিয়ে নয়।
প্রকল্প এনভায়রনমেন্ট যা করতে পারে না তা হলো ডিস্ট্রিবিউশন-প্যাকেজকৃত ফ্রন্টএন্ড মেরামত করা। ওই প্রোগ্রামের নির্ভরতাগুলো প্যাকেজ ম্যানেজার যে ইন্টারপ্রেটার বেছেছিল তার জন্য নির্মিত, এবং আপনার প্রকল্পের এনভায়রনমেন্টের ভেতরে এটি চালানো হয় ব্যর্থ হয়, নয়তো এমন মিশ্রণ তৈরি করে যা কেউ সমর্থন করে না। এনভায়রনমেন্ট ভেরিয়েবল দিয়ে এতে পাথ ঢোকানো অতিরিক্ত ধাপসহ একই ভুল: টুলটি কী লোড করে তা আপনি বদলেছেন, কিন্তু কিসের বিপরীতে তার পরীক্ষা হয়েছিল তা বদলাননি। এই বিনিময়টি ঠিক ততক্ষণ পর্যন্ত সমাধানের মতো দেখায়, যতক্ষণ না পরবর্তী ইমপোর্টে গিয়ে ঠেকতে হয়।
সিস্টেমের ইন্টারপ্রেটার পুনর্নির্দেশ করা কেন ফাঁদ
ডিফল্ট ইন্টারপ্রেটার বদলানো আকর্ষণীয়, কারণ মনে হয় এটি এক কমান্ডেই ট্রেসব্যাক ঠিক করে দেয়। এটি হোস্টের প্রতিটি প্যাকেজকৃত Python টুল যে ধারণার ওপর নির্মিত তা-ও ভেঙে দেয়, আর ব্যর্থতাগুলো পরে ও অসম্পর্কিত জায়গায় দেখা দেয়।
বিকল্প-নির্বাচন ব্যবস্থাগুলো সমতুল্য বাস্তবায়নের মধ্যে বদলানোর জন্য তৈরি, পুরোনো কম্পাইলকৃত মডিউলের নিচে নতুনতর ভাষা ইনস্টল করার জন্য নয়। কম্পাইলকৃত এক্সটেনশন নির্দিষ্ট ABI-র জন্য নির্মিত হয়, তাই গতকাল যে মডিউল ইমপোর্ট হয়েছিল সেটি আজ একটি প্যাকেজও না সরিয়েই লোড হতে ব্যর্থ হতে পারে।
মানুষের পাওয়া পরামর্শে নাম নিয়ে একটি ফাঁদও আছে। সংস্করণহীন python কমান্ডের ডিস্ট্রিবিউশন ও এনভায়রনমেন্টজুড়ে একটিই সর্বজনীন অর্থ নেই, এবং এটিকে নির্দিষ্ট একটি প্রধান সংস্করণের স্থির সমার্থক হিসেবে ধরা এমন সমাধান দেয় যা কেবল যে মেশিনে লেখা হয়েছিল সেখানেই কাজ করে। ব্লগ পোস্টের নয়, আপনার সামনের সিস্টেমের নীতি পড়ুন।
আলাদা গ্রহণযোগ্যতা পরীক্ষা
শেষে দুটি পরীক্ষা থাকা উচিত, আর একটিতে উত্তীর্ণ হওয়া অন্যটি সম্পর্কে কিছুই বলে না। প্রথমটি হলো সমর্থিত ক্লায়েন্ট কমান্ডটি যে ইন্টারপ্রেটারের জন্য প্যাকেজ করা হয়েছিল তার সঙ্গে কাজ করে। দ্বিতীয়টি হলো বিশেষাধিকারপ্রাপ্ত সার্ভিস একটি সেশন প্রতিষ্ঠা করে এবং টানেল ট্রাফিক বহন করে।
openvpn3 sessions-list
openvpn3-service-client --help 2>/dev/null | head -n 3
ip -4 addr show tun0
কাজ করার সময় মেশিনে ঢোকার একটি স্বাধীন পথ রাখুন, বিশেষত যদি VPN আপনার একমাত্র প্রশাসনিক প্রবেশপথ বহন করে। সিস্টেমের ইন্টারপ্রেটারে পরিবর্তন ঠিক সেই ধরনের সম্পাদনা যা পথের মাঝেই সেই প্রবেশপথ সরিয়ে দিতে পারে।
ব্যর্থতা যদি সিস্টেম টুলের জন্য অনুপস্থিত মডিউল হয়, তবে সংশোধন হলো সমর্থিত কর্মপ্রবাহের মাধ্যমে একটি প্যাকেজ অপারেশন। ব্যর্থতা যদি আপনার নিজের প্রকল্পে সংস্করণ দ্বন্দ্ব হয়, তবে সংশোধন হলো একটি এনভায়রনমেন্ট। এই দুটির মধ্যে বেছে নেওয়াই পুরো সিদ্ধান্ত, এবং তা নির্ধারিত হয় কোন প্রোগ্রাম ট্রেসব্যাকটি ছেপেছে তা দিয়ে।