আপনার VPN বাইনারি কি এই CPU-র জন্য তৈরি? ELF হেডার পড়ুন

দুটি ফাইলই 32-বিট এবং তাদের মধ্যে কেবল একটি আপনার বোর্ডে চলে। Intel-এর জন্য ELF32 বিল্ড এবং ARM-এর জন্য ELF32 বিল্ড ক্লাস ফিল্ডে একমত এবং যেসব বিষয় গুরুত্বপূর্ণ তাতে ভিন্ন। 32-বিট বিকল্প দেওয়া একটি ডাউনলোড পৃষ্ঠা আপনি যে ফাইলটি সত্যিই ডাউনলোড করেছেন তার হেডার না পড়া পর্যন্ত আপনাকে প্রায় কিছুই বলেনি। এর নাম বদলালে একটি নির্দেশও বদলায় না।

ক্লাস ও মেশিন ভিন্ন প্রশ্নের উত্তর দেয়

ক্লাস ফিল্ড বলে ফাইলটি 32-বিট না 64-বিট কাঠামো ব্যবহার করে। মেশিন ফিল্ড সেই নির্দেশ সেটের নাম দেয় যার জন্য ফাইলটি কম্পাইল করা হয়েছে। কেবল প্রথমটি পড়াই হলো সেই উপায় যাতে একটি x86 বিল্ড সম্পূর্ণ বিশ্বাসযোগ্য দেখতে ফাইলের নাম নিয়ে একটি ARM বোর্ডে পৌঁছে যায়। দুটি মানই একই কমান্ড থেকে আসে, তাই একটি বাদ দেওয়া এত সহজ।

একই বিভ্রান্তি 64-বিট লেবেলের ক্ষেত্রেও প্রযোজ্য, যেখানে aarch64 এবং x86-64 একটি শব্দের আকার ভাগ করে এবং কোনো নির্দেশই ভাগ করে না। একটি 64-বিট ডাউনলোড তালিকাভুক্ত করা একটি বিক্রেতার পৃষ্ঠা তার নিজের বিল্ড বর্ণনা করছে, আপনার মেশিন নয়। পৃষ্ঠার কলাম শিরোনামের বদলে ফাইলের হেডার দেখুন।

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

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

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

ইনস্টলার চালানোর আগে হেডার পড়ুন

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

মেশিন ফিল্ডকে চলমান সিস্টেমের প্যাকেজ আর্কিটেকচারের সাথে তুলনা করুন, বোর্ডের বিপণন নামের সাথে নয়। 32-বিট ইউজারল্যান্ড চালানো একটি 64-বিট CPU-র 32-বিট বিল্ড দরকার, এবং সেই বিশদটিই ঠিক করে কোন ডাউনলোড নেটিভ। বোর্ডের সামর্থ্য সীমাবদ্ধতা নয়; ইনস্টল করা ইউজারল্যান্ডই সীমাবদ্ধতা।

dpkg --print-architecture
uname -m
getconf LONG_BIT

প্রথম কমান্ডটি যে আর্কিটেকচারের জন্য সিস্টেম প্যাকেজ ইনস্টল করে তা জানায়, আর সেই মানটিই মিলতে হবে। বাকি দুটি কার্নেল ও শব্দের আকার বর্ণনা করে, এবং মাল্টিআর্ক ইনস্টলে তারা ইউজারল্যান্ডের সাথে অমিল হতে পারে।

যখন সেই উত্তরগুলি অমিল হয়, আরেকটি আর্কাইভ ডাউনলোড করার আগে ঠিক করুন বিক্রেতা কোনটি সমর্থন করে। অনুমান ইনস্টলেশনের একটি চক্র তৈরি করে যার প্রতিটি ভিন্ন বিন্দুতে ব্যর্থ হয়, এবং প্রতিটি ব্যর্থতা নতুন সমস্যার মতো দেখায়।

ইন্টারপ্রিটর পরীক্ষা করুন, কেবল আর্কিটেকচার নয়

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

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

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

প্রথম কমান্ডটি বাইনারি যে ইন্টারপ্রিটর পাথ চায় তা দেখায়। দ্বিতীয়টি যাচাই করে সেই পাথ বিদ্যমান কি না, যা ভুল বিল্ডকে অনুপস্থিত লোডার থেকে আলাদা করে।

অবিশ্বস্ত বাইনারির বিরুদ্ধে নির্ভরতা-তালিকা চালাবেন না, কারণ কিছু বাস্তবায়ন তারা যে ফাইল পরিদর্শন করে তা চালাতে পারে। পরিদর্শন কেবল-পঠনযোগ্য রাখুন এবং একটি অসমর্থিত বিল্ড চালু করতে লোডার সিমলিংক যোগ করার প্রবণতা প্রতিরোধ করুন।

তথ্য হাতে নিয়ে একটি বিল্ড চান

বিক্রেতাকে OS রিলিজ, প্যাকেজ আর্কিটেকচার, ক্লাস ও মেশিনের মান এবং প্রথম ত্রুটি বার্তা পাঠান। সেই সমন্বয় একটি কাজে লাগার মতো উত্তর পায়, আর সাধারণ ব্যর্থতার স্ক্রিনশট একটি সাপোর্ট টেমপ্লেট পায়।

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