আপনার Raspberry Pi-র জন্য কি পুরোনো openfortivpn .deb ফাইলটি সঠিক?

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

ফাইলনামটি নীরবে যা আটকে রাখে

openfortivpn_1.17.0-1_armhf.deb-এর মতো একটি নাম ডান থেকে বাঁয়ে পড়ুন। প্রত্যয়টি হলো যে আর্কিটেকচারের জন্য বাইনারিটি কম্পাইল করা হয়েছে, মাঝের ক্ষেত্রটি হলো আপস্ট্রিম ও প্যাকেজিং রিভিশন, আর অন্তর্নিহিত চতুর্থ ক্ষেত্রটি হলো যে স্যুটে এটি তৈরি হয়েছিল তার লাইব্রেরি সেট।

64-বিট Raspberry Pi OS ইনস্টলে সিস্টেম আর্কিটেকচার হলো arm64, তাই dpkg -i আর্কিটেকচার অমিলের কারণে একটি armhf প্যাকেজ প্রত্যাখ্যান করে। যেখানে multiarch ইনস্টল করা সম্ভব করে, সেখানেও বাইনারিটি যে রিলিজের বিপরীতে তৈরি হয়েছিল সেই রিলিজের লাইব্রেরি সংস্করণ প্রত্যাশা করে, আর নতুন বেস সিস্টেম সেগুলো আর নাও দিতে পারে। ফলাফল হলো একটি ইনস্টল করা প্যাকেজ যার এক্সিকিউটেবল চালু হতে পারে না, আর এটিই সেই ব্যর্থতা যা মানুষ সাধারণত ক্লায়েন্টটিকেই নষ্ট ভেবে ভুল করে।

বোর্ডটি ARM ডিভাইস হওয়া কোনো ARM প্যাকেজকে উপযুক্ত করে না। আর্কিটেকচার একটি অক্ষ; রিলিজ ও ABI অন্য দুটি, এবং তারা স্বাধীনভাবে ব্যর্থ হয়।

ডাউনলোড লিংক চাওয়ার আগে ডিস্ট্রিবিউশনকে জিজ্ঞাসা করুন

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

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

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

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

apt কী যাচাই করে, আর ডাউনলোড করা ফাইল কী পায় না

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

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

পুরোনো নির্দেশনা চালু রাখতে স্বাক্ষর ত্রুটি চেপে যাওয়া বা TLS যাচাই বন্ধ করা প্রক্রিয়ার একমাত্র অংশটিকেই সরিয়ে দেয় যা কিছু যাচাই করছিল। বরং ব্যর্থ হওয়া যাচাইটি পুনরুদ্ধার করুন।

ক্লায়েন্ট ইনস্টল করুন, তারপর সংযোগ আলাদাভাবে ডিবাগ করুন

রক্ষণাবেক্ষণকৃত প্রার্থী থাকলে স্বাভাবিক পর্যালোচিত লেনদেনের মাধ্যমে তা ইনস্টল করুন এবং প্যাকেজ ম্যানেজারকে কী করেছে তা লিপিবদ্ধ করতে দিন।

যদি ডিপ্লয়মেন্টের সত্যিই আপস্ট্রিম বিল্ড দরকার হয়, প্রজেক্টের বর্তমান বিল্ড নির্দেশনা অনুসরণ করুন এবং এটিকে এখন আপনি রক্ষণাবেক্ষণ করা সফটওয়্যার হিসেবে দেখুন: ডেভেলপমেন্ট প্যাকেজ, pkg-config, TLS লাইব্রেরির হেডার এবং PPP ডিমন বাস্তব নির্ভরতা, আর পরবর্তীতে আপনার প্রয়োজন হবে এমন অপসারণ পদ্ধতিও তাই।

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

পুরোনো ফাইলনামের জায়গা নেওয়ার পরিকল্পনা

প্রথমে প্ল্যাটফর্ম পরিচয় লিখুন: OS রিলিজ, আর্কিটেকচার এবং ব্যবহৃত সোর্স তালিকা। তারপর প্যাকেজটি কোথা থেকে আসে সেই অনুমোদিত স্থানের নাম দিন—তা ডিস্ট্রিবিউশন রিপোজিটরি, পিন করা কীসহ ভেন্ডর রিপোজিটরি, বা আপনি নিজে কম্পাইল ও প্যাকেজ করা বিল্ড হতে পারে।

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

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