কেন একটি OpenVPN হুক তার স্ক্রিপ্টের পাশের ফাইলটি খুঁজে পায় না

ত্রুটি ছাড়া চলেও যেসব হুক হারানো ফাইলের কথা জানায়, তারা সাধারণত ভুল জায়গায় খোঁজে, কাজে ব্যর্থ হয় না। স্ক্রিপ্টের আপেক্ষিক পাথ প্রক্রিয়ার কার্যকারী ডিরেক্টরির সাপেক্ষে সমাধান হয়, আর একটি সার্ভিস এমন কার্যকারী ডিরেক্টরি নিয়ে শুরু হয় যা আপনি বেছে নেননি। স্ক্রিপ্টের পাশের ফাইল আর প্রক্রিয়া যে ফাইলটি খোলে, কেবল তখনই একই জিনিস যখন কিছু তাদের অ্যাঙ্কর করে। এই ফাঁকই হুক ব্যর্থতার বড় অংশের ব্যাখ্যা দেয়, যেগুলো ভুলভাবে অনুমতির সমস্যা হিসেবে পড়া হয়।

অনুমতির আগে পাথটি যাচাই করুন, কারণ ভুল ফাইলে অনুমতির ত্রুটি তবুও ভুল ফাইলই।

আপেক্ষিক পাথ ফাইলের নয়, প্রক্রিয়ার সাপেক্ষে সমাধান হয়

যখন একটি স্ক্রিপ্ট open("policy.json") কল করে, কার্নেল নামটি প্রক্রিয়ার বর্তমান কার্যকারী ডিরেক্টরির সাপেক্ষে সমাধান করে। স্ক্রিপ্টের নিজের অবস্থানের কিছুই সেই অনুসন্ধানে অংশ নেয় না। OpenVPN নিজে যে ডিরেক্টরি বেছে নেয় সেখান থেকে হুক চালায়, আর cd অপশন সেটি বদলাতে পারে, তাই নিজের ফোল্ডার থেকে হাতে পরীক্ষা করা স্ক্রিপ্ট ডেমন চালালে ভিন্নভাবে আচরণ করে। হাতের পরীক্ষা পাস করে, সার্ভিস চালানো ব্যর্থ হয়, আর লগের লাইন কেবল হারানো নামটির কথা বলে।

Python স্ক্রিপ্টের অবস্থানকে __file__ হিসেবে প্রকাশ করে, আর সেটিই অ্যাঙ্কর সম্ভব করে। Path(__file__).resolve().parent / "policy.json" প্রক্রিয়া থেকে নয়, ফাইল থেকে পাথ তৈরি করে। ওই একটি লাইন সুবিধায় কিছু না বদলেই কার্যকারী ডিরেক্টরির নির্ভরতা সরিয়ে দেয়।

পাথটি সচেতনভাবে অ্যাঙ্কর করুন, তারপর resolve কী করে দেখুন

resolve() সিম্বলিক লিংক অনুসরণ করে, তাই যে ইনস্টলেশন হুকটিকে জায়গায় লিংক করে, সেটি লিংকের লক্ষ্যে অ্যাঙ্কর হয়, লিংক ধরে রাখা ডিরেক্টরিতে নয়। ভার্সনযুক্ত ডিপ্লয়ের জন্য সাধারণত এটাই চাওয়া হয়, আর সিম্বলিক লিংকের পাশে ডেটা প্রত্যাশা করা লেআউটের জন্য এটি ভুল। ডিপ্লয় কোনটি বোঝায় তা ঠিক করুন এবং প্রোডাকশনে পার্থক্য আবিষ্কার না করে সেই অনুযায়ী কোড লিখুন। Path(__file__).parent, resolve() ছাড়া লিংকের নিজের ডিরেক্টরি রাখে।

যদি ডেটা প্রোগ্রামের নয়, ইনস্ট্যান্সের হয়, তবে কনফিগারেশন থেকে একটি পরম পাথ নিন। অবস্থান হার্ডকোড করলে হুক একটি হোস্ট লেআউটের সাথে বাঁধা পড়ে।

চারটি সীমানা ক্রমানুসারে পার করুন

কার্যকারী ডিরেক্টরি দিয়ে শুরু করুন: ইউনিটের WorkingDirectory, OpenVPN-এর cd অপশন এবং exec-এর আগে ডিরেক্টরি বদলায় এমন যেকোনো র্যাপার তুলনা করুন। তারপর সমাধান হওয়া অবস্থান নিশ্চিত করুন, কারণ অন্য ডিপ্লয়ে একই নামের ফাইল অনুসন্ধানের উত্তর দিয়ে ভুলটি লুকাতে পারে। এরপর আসে ফাইলসিস্টেম দৃশ্য: chroot বা সার্ভিসের মাউন্ট নেমস্পেস একটি পরম হোস্ট পাথকে সহজেই অনুপস্থিত করে দিতে পারে। শেষে অ্যাক্সেস পরিচয়, যা দৃশ্যমানতা থেকে আলাদা প্রশ্ন।

ProtectHome এবং PrivateTmp ভিন্ন অবস্থান লুকায়, আর কোনোটিই হোস্ট থেকে নেওয়া ডিরেক্টরি তালিকায় দেখা যায় না। শেলে root-এর জন্য থাকা একটি পাথ ইউনিটের নেমস্পেসের ভিতরে অদৃশ্য হতে পারে, তাই সার্ভিসের বাইরে একই কমান্ড পরীক্ষা করে খুব কমই প্রমাণ হয়।

সার্ভিস প্রশস্ত না করেই অনুসন্ধান ঠিক করুন

পাথ অ্যাঙ্কর করা কেবল প্রথম সীমানার সমাধান করে। এটি সার্ভিস যে ডিরেক্টরি লুকায় তা প্রকাশ করে না, আর root-কেবল ফাইলে অনুপ্রবেশাধিকারহীন অ্যাকাউন্টকে প্রবেশাধিকার দেয় না। script-security কোন স্ক্রিপ্ট OpenVPN চালাবে তা বদলায়; আপেক্ষিক নাম কোথায় সমাধান হয় তাতে কোনো প্রভাব নেই। পুরো সার্ভিসের জন্য কার্যকারী ডিরেক্টরি বদলানো সমস্যার চেয়ে প্রশস্ত, কারণ অন্য প্রতিটি আপেক্ষিক সার্টিফিকেট, লগ বা সহায়ক পাথ তার সাথে সরে যায়।

সংকীর্ণ সমাধান বেছে নিন: স্ক্রিপ্টে একটি নির্ধারক পাথ, ইনস্ট্যান্স ডেটার জন্য স্পষ্ট কনফিগারেশন মান, এবং হুক যে অ্যাকাউন্ট হিসেবে সত্যিই চলে তার সাথে মিলে যাওয়া ফাইল মালিকানা।

সীমানার নাম বলে এমন প্রমাণ লিপিবদ্ধ করুন

উপযোগী ব্যর্থতার প্রতিবেদনে তিনটি জিনিস থাকে: হুক যে সঠিক পাথটি চেষ্টা করেছে, যে পরিবেশ তা তৈরি করেছে, এবং কোন সীমানা অস্বীকার করেছে। ফাইলের বিষয়বস্তু না ঢেলে সমাধান হওয়া পাথ ও ব্যতিক্রমটি ছাপুন। এই ত্রয়ী ভুল অ্যাঙ্করকে লুকানো মাউন্ট থেকে এবং অনুমতি প্রত্যাখ্যান থেকে আলাদা করে, আর এগুলো তিনটি ভিন্ন সমাধান।

root টার্মিনাল থেকে ফাইলটি পড়তে পারে এই দাবি ওই প্রশ্নগুলোর একটির উত্তর দেয়, বাকিগুলোর কোনোটির নয়। বরং সার্ভিসের নিজের প্রেক্ষাপট থেকে পরীক্ষা করুন।