Linux distribution-এর ইতিহাস ও বিবর্তন

Linux distribution আসলে কী

Linux distribution-এর ইতিহাস একটি শূন্যস্থান দিয়ে শুরু হয়: Linux kernel নিজে থেকে এমন কিছু করতে পারে না যা একজন ব্যবহারকারী কাজে লাগাতে পারেন। এটি বুট হয় এবং হার্ডওয়্যার খুঁজে পায়। তারপর এটি থেমে যায়। কাউকে একটি userland যোগ করতে হয়, সফটওয়্যার কীভাবে ইনস্টল ও আপডেট হবে তা নির্বাচন করতে হয় এবং বছরের পর বছর ধরে তা ঠিক রাখার প্রতিশ্রুতি দিতে হয়। একটি distribution হলো সেই সব পছন্দের সমষ্টি, এবং সেই সাথে একদল মানুষ যারা পরবর্তীতে এর রক্ষণাবেক্ষণ করেন।

এর পাঁচটি অংশ রয়েছে। এর যেকোনো একটি পরিবর্তন করলে আপনি একটি ভিন্ন distribution পাবেন, এমনকি যখন অধিকাংশ binary মিলে যায় তবুও:

• একটি kernel, যা প্রজেক্টের বাছাই করা ভার্সনের, সাথে তাদের যোগ করা patch এবং driver।
• একটি userland: C library, shell, init system এবং standard command।
• একটি package format এবং এটি ইনস্টল করার টুল।
• একটি release policy: কী পরিবর্তন করা যাবে, কত ঘনঘন করা যাবে এবং প্রতিটি release কতদিন পর্যন্ত ঠিক রাখা হবে।
• মানুষ: package maintainer, একটি security team এবং এমন কেউ যিনি কোনো package নষ্ট হয়ে গেলে তার উত্তর দেন।

Kernel হলো সাধারণ অংশ, তাই দুটি Linux distribution একে অপরের যতটা কাছাকাছি থাকে, তার কোনোটিই অন্য কোনো Unix-এর ততটা কাছাকাছি থাকে না। যখন আপনি server platform হিসেবে Linux এবং FreeBSD-এর তুলনা করবেন, তখন এই বিষয়টি মনে রাখা জরুরি, যেখানে kernel এবং base userland একটি প্রজেক্ট দ্বারা তৈরি হয় এবং একসাথে release করা হয়। Linux-এ এই অংশগুলো আলাদা আলাদা upstream থেকে আসে এবং distribution হলো সেই মাধ্যম যা এদের মধ্যে সমন্বয় সাধন করে।

লিনাক্স ডিস্ট্রিবিউশনের তিনটি পরিবারের ইতিহাস

1993 এবং 1994 সালে শুরু হওয়া তিনটি প্রজেক্ট থেকে তিনটি পরিবারের উদ্ভব হয়: Slackware, Debian এবং Red Hat। বর্তমানে যেকোনো VPS কন্ট্রোল প্যানেলে থাকা প্রায় প্রতিটি ইমেজই এই তিনটি পরিবারের কোনো একটি বা এদের বংশোদ্ভূত। একটি ডেরিভেটিভ বা বংশোদ্ভূত ডিস্ট্রিবিউশন তার মূল ডিস্ট্রিবিউশনের প্যাকেজ ফরম্যাট, ফাইল লেআউট এবং সাধারণত রিলিজের অভ্যাসগুলো উত্তরাধিকার সূত্রে পায়। এই কারণেই ব্র্যান্ডিং সরিয়ে ফেলার পরেও একটি Debian ডেরিভেটিভকে অনেকটা Debian-এর মতোই মনে হয়।

স্বাধীন ডিস্ট্রিবিউশনগুলো আলাদা আলোচনার দাবি রাখে, কারণ তারা অন্য কোনো ডিস্ট্রিবিউশন থেকে ফর্ক (fork) করা নয়। Arch, Gentoo, Alpine, NixOS এবং Void—এদের প্রত্যেকেই নিজস্ব প্যাকেজ ম্যানেজার এবং নিজস্ব নিয়ম তৈরি করেছে। এদের মধ্যে দুটি, Arch এবং Alpine, শেষ পর্যন্ত আপনার প্রোভাইডারের ইমেজ তালিকায় জায়গা করে নিয়েছে, যার কারণগুলো ডেস্কটপ ব্যবহারের সাথে সম্পর্কিত নয়।

1992: ডিস্ট্রিবিউশন বা পরিবারের পূর্বসূরি

MCC Interim Linux 1992 সালের ফেব্রুয়ারি মাসে প্রকাশিত হয়, যা ম্যানচেস্টার কম্পিউটিং সেন্টারে ওয়েন লে ব্লাঙ্ক (Owen Le Blanc) তৈরি করেছিলেন। এটি একটি মেনু-চালিত ইনস্টলারের মাধ্যমে কার্নেল এবং GNU (GNU's not Unix) টুলগুলোকে দুটি ফ্লপি ইমেজে অন্তর্ভুক্ত করেছিল। এটি তৈরি করার কারণ ছিল, হাতে এই কাজ করতে একদিনের বেশি সময় লাগত।

পিটার ম্যাকডোনাল্ড (Peter MacDonald) 1992 সালে SLS (Softlanding Linux System) প্রকাশ করেন, যা আরও এক ধাপ এগিয়ে X (the X Window System) এবং TCP/IP নেটওয়ার্কিং যুক্ত করে। distribution শব্দটি বর্তমানে যে অর্থে ব্যবহৃত হয়, তার মূল কারণ হলো SLS। এটি ত্রুটিপূর্ণ ছিল এবং এর রক্ষণাবেক্ষণও ছিল ধীরগতির। 1993 সালে দুজন ব্যক্তি আলাদাভাবে এই সমস্যা সমাধানের সিদ্ধান্ত নেন। একজন এটিকে নতুন করে তৈরি করেন। অন্যজন লিখিত নিয়মের ভিত্তিতে একেবারে নতুন করে শুরু করেন।

Slackware, 1993: টিকে থাকা প্রাচীনতম পরিবার

Patrick Volkerding 16 জুলাই 1993 সালে Slackware 1.00 রিলিজ করেন, যা SLS থেকে তৈরি করা হয়েছিল এবং এর ত্রুটিগুলো সংশোধন করা হয়েছিল। এটি এখনও রক্ষণাবেক্ষণ করা হয়, যা এটিকে টিকে থাকা প্রাচীনতম Linux ডিস্ট্রিবিউশন হিসেবে প্রতিষ্ঠিত করেছে।

একটি Slackware প্যাকেজ হলো একটি কম্প্রেসড tar আর্কাইভ, যার ভেতরে একটি ইনস্টল স্ক্রিপ্ট থাকে। এতে কোনো dependency resolution নেই: আপনার নতুন প্যাকেজের জন্য প্রয়োজনীয় লাইব্রেরিটি ডিস্কে আগে থেকেই আছে কি না, তা পরীক্ষা করার কোনো ব্যবস্থা নেই। এই একটি সিদ্ধান্তই বাকি সবকিছুকে প্রভাবিত করেছে। যেহেতু টুলটি dependency সমাধান করবে না, তাই রিলিজের সেটটিকে গঠনগতভাবে সামঞ্জস্যপূর্ণ হতে হয়, যার ফলে রিলিজগুলো খুব কম এবং রক্ষণশীল হয়। Slackware 15.0 এসেছিল ফেব্রুয়ারি 2022 সালে, যা 14.2-এর ছয় বছর পর।

এই পরিবারটি ছোট। 1990-এর দশকের মাঝামাঝি সময়ে SUSE-এর প্রাথমিক রিলিজগুলো Slackware-এর ওপর ভিত্তি করে তৈরি হয়েছিল, পরবর্তীতে প্রকল্পটি YaST এবং তারও পরে RPM প্যাকেজ ফরম্যাট নিয়ে নিজস্ব পথে চলে যায়। এই শেষ অংশটি মানুষকে বিভ্রান্ত করে। SUSE এবং openSUSE RPM প্যাকেজ ব্যবহার করে, কিন্তু তারা Red Hat-এর ডেরিভেটিভ নয়। ফরম্যাটটি স্থানান্তরিত হয়েছে, কিন্তু বংশধারা নয়।

Debian, 1993: একটি সামাজিক চুক্তি এবং তিনটি সুইটের পাইপলাইন

Ian Murdock 16 আগস্ট 1993 সালে Debian-এর ঘোষণা দেন, যা Slackware আসার তিন সপ্তাহ পরের ঘটনা এবং এর কারণও একই ছিল। তার সঙ্গী Debra এবং নিজের নামের সমন্বয়ে এই নামকরণ করা হয়। 1994 সালের জানুয়ারিতে Debian Manifesto প্রকাশিত হয় এবং শর্ত নির্ধারণ করে: এই ডিস্ট্রিবিউশনটি কোনো কোম্পানির দ্বারা নয়, বরং স্বেচ্ছাসেবকদের দ্বারা উন্মুক্তভাবে পরিচালিত হবে।

Debian এরপর শর্তগুলো লিখিত আকারে প্রকাশ করে। 1997 সালের জুলাই মাসে Debian Social Contract এবং DFSG (Debian free software guidelines) গৃহীত হয় এবং 1998 সালে DFSG-ই Open Source Definition-এর ভিত্তি হয়ে ওঠে। একটি ডিস্ট্রিবিউশনে কী থাকবে তা নির্ধারণ করার জন্য লেখা একটি নথি শেষ পর্যন্ত পুরো ইন্ডাস্ট্রির জন্য একটি লাইসেন্স ক্যাটাগরি সংজ্ঞায়িত করে। আপনার sources.list-এ বিভিন্ন অংশ থাকার কারণও এটিই: main-এ সেই সফটওয়্যার থাকে যা গাইডলাইন মেনে চলে, contrib এবং non-free-এ যা মেনে চলে না তা থাকে, এবং Debian 12-এ non-free-firmware যুক্ত করা হয়েছে যাতে একটি ওয়্যারলেস কার্ড থাকা ল্যাপটপে কোনো ঝামেলা ছাড়াই ইনস্টলেশন সম্পন্ন করা যায়।

টুলিং হলো আরেকটি উত্তরাধিকার। dpkg একটি প্যাকেজ ইনস্টল করে এবং কোনো কিছু অনুপস্থিত থাকলে তা প্রত্যাখ্যান করে dpkg: dependency problems prevent configuration of প্রিন্ট করে। APT (advanced package tool), যা 1999 সালে Debian 2.1-এর সাথে ডিফল্ট হিসেবে আসে, সেটিই সেই স্তর যা নির্ধারণ করে আর কী কী আনতে হবে এবং কোন ক্রমে আনতে হবে। প্রতিটি Debian ডেরিভেটিভের প্রতিটি apt কমান্ড সেই কাজেরই ধারাবাহিকতা।

রিলিজ মেশিনে তিনটি সুইট এবং একটি নিয়ম রয়েছে। একজন মেইনটেইনার unstable-এ আপলোড করেন, যার কোডনেম স্থায়ীভাবে sid। একটি স্ক্রিপ্ট প্রায় 5 থেকে 10 দিন পর প্যাকেজটিকে testing-এ স্থানান্তর করে, যদি এটি রিলিজ আর্কিটেকচারে বিল্ড হয় এবং নতুন কোনো রিলিজ ক্রিটিক্যাল বাগ না থাকে। এরপর testing ফ্রিজ করা হয়, রিলিজ টিম অবশিষ্ট সমস্যাগুলো সমাধান করে এবং বাগের তালিকা যথেষ্ট ছোট হলে stable রিলিজ দেওয়া হয়। কোনো নির্দিষ্ট তারিখের ভিত্তিতে নয়। এই কারণেই Debian stable দেখতে পুরনো মনে হলেও এটি খুব স্থিতিশীল: ফ্রিজ হওয়ার সময় ভার্সন নম্বরগুলো স্থির হয়ে যায়, কিন্তু নিরাপত্তা সংক্রান্ত ফিক্সগুলো সেগুলোতে ব্যাকপোর্ট করা হতে থাকে।

গভর্নেন্স বা শাসন ব্যবস্থাও লিখিত, যেখানে একজন নির্বাচিত প্রজেক্ট লিডার এবং বাধ্যতামূলক জেনারেল রেজোলিউশন থাকে। 2014 সালে সেই প্রক্রিয়াটি systemd-কে ডিফল্ট init সিস্টেম হিসেবে বেছে নেয় এবং যারা এর সাথে একমত ছিলেন না তারা Devuan ফর্ক করেন, যা 2017 সালে প্রথম রিলিজ পায়। Debian এই পরিবর্তনের প্রথম বা শেষ ডিস্ট্রিবিউশন ছিল না, এবং কেন এটি বারবার ঘটতে থাকে, সেই সাথে যেসব আপত্তি সঠিক প্রমাণিত হয়েছিল, তার বিস্তারিত কিভাবে systemd SysV init-কে প্রতিস্থাপন করেছে তার বিবরণ-এ পাওয়া যাবে। এর বড় বংশধরদের মধ্যে রয়েছে Ubuntu, Raspberry Pi OS, Proxmox VE, Kali এবং Linux Mint।

Red Hat, 1994: RPM, এবং পরবর্তীতে Fedora ও RHEL-এ বিভাজন

Marc Ewing 1994 সালের হ্যালোইনের কাছাকাছি সময়ে প্রথম Red Hat Linux প্রকাশ করেন। Bob Young-এর কোম্পানি 1995 সালে এটি কিনে নেয় এবং তারা দুজনে মিলে প্রথম এমন একটি Linux ব্যবসা গড়ে তোলেন যেখানে সফটওয়্যারের পরিবর্তে সাপোর্ট বিক্রি করা হতো। 11 আগস্ট 1999 সালে Red Hat পাবলিক লিমিটেড কোম্পানিতে পরিণত হয়। 2019 সালের জুলাই মাসে IBM প্রায় 34 বিলিয়ন ডলারে কোম্পানিটিকে অধিগ্রহণ সম্পন্ন করে, তাই যে ডিস্ট্রিবিউশনের ওপর ভিত্তি করে বেশিরভাগ এন্টারপ্রাইজ সফটওয়্যার সার্টিফাইড হয়, তা তখন থেকেই IBM-এর মালিকানাধীন।

এর দীর্ঘস্থায়ী প্রযুক্তিগত অবদান হলো RPM (Red Hat package manager), যা 1995 সালে Red Hat Linux 2.0-এর জন্য Erik Troan এবং Marc Ewing তৈরি করেছিলেন। একটি RPM তার ডিপেন্ডেন্সিগুলো ঘোষণা করে এবং এটি একটি spec file থেকে তৈরি হয়, যা মূলত একটি বিল্ড রেসিপি যা যে কেউ চালাতে পারে। এই দ্বিতীয় বৈশিষ্ট্যটির কারণেই পরবর্তীতে Red Hat-এর এন্টারপ্রাইজ প্রোডাক্টের স্বাধীন রি-বিল্ড তৈরি করা সম্ভব হয়েছিল।

2003 সালের Red Hat Linux 9 ছিল মূল ধারার শেষ সংস্করণ। কোম্পানিটি এটিকে দুই ভাগে বিভক্ত করে: 2003 সালের নভেম্বরে দ্রুতগতির কমিউনিটি রিলিজ হিসেবে Fedora Core 1 এবং 2002 সালে Advanced Server 2.1 হিসেবে শুরু হওয়া ধীরগতির পেইড ভার্সন RHEL (Red Hat Enterprise Linux)। এর কারণ স্পষ্ট। একটি প্রোডাক্ট একই সাথে নতুন ভার্সন পরীক্ষার জায়গা এবং এমন একটি প্ল্যাটফর্ম হতে পারে না যা একটি ব্যাংক দশ বছর ধরে কোনো পরিবর্তন ছাড়াই ব্যবহার করবে। এই দুটি অংশ একে অপরের সাথে যুক্ত: একটি RHEL মেজর ভার্সন Fedora রিলিজ থেকে শাখা হিসেবে বের হয়, স্থিতিশীল হয় এবং তারপর ফ্রিজ বা স্থায়ী করা হয়। প্যাকেজ টুলটিও একই সময়সূচী মেনে চলেছে, 2000-এর দশকে yum থেকে 2015 সালে Fedora-এর ডিফল্ট হিসেবে dnf-এ উন্নীত হয়েছে, যার নিচে উভয় ক্ষেত্রেই rpm কাজ করে।

কেন CentOS একটি ফ্রি RHEL রিবিল্ড হিসেবে থাকা বন্ধ করে দিয়েছে

CentOS 2004 সালে একটি সাধারণ কাজ নিয়ে শুরু হয়েছিল: Red Hat-এর প্রকাশিত সোর্স প্যাকেজগুলো নেওয়া, ট্রেডমার্কগুলো সরিয়ে ফেলা, সেগুলো পুনরায় বিল্ড করা এবং ফলাফলটি বিনামূল্যে বিতরণ করা। এটি এক দশকের জন্য ডিফল্ট ফ্রি সার্ভার ডিস্ট্রিবিউশন হয়ে ওঠে এবং 2014 সালে Red Hat প্রকল্পটিকে নিজেদের অধীনে নিয়ে নেয়।

8 ডিসেম্বর 2020-এ Red Hat ঘোষণা করে যে, CentOS Linux 8-এর মেয়াদ 31 ডিসেম্বর 2021-এ শেষ হবে, যা নির্ধারিত তারিখের আট বছর আগেই। তারা জানায় যে, CentOS Stream নামে এই নামটি টিকে থাকবে। Stream কোনো রিবিল্ড নয়। এটি সেই শাখা যেখান থেকে RHEL-এর মাইনর রিলিজগুলো তৈরি হয়, তাই এটি RHEL-এর পেছনে চলার পরিবর্তে তার আগেই চলে। আপনি যদি এমন কোনো মেশিন চান যা বছরের পর বছর ব্যবহার করবেন, তবে 'সামনে থাকা' ভুল দিক, কারণ Red Hat-এর পেইড গ্রাহকদের আগেই আপনি পরিবর্তনগুলো পেয়ে যাবেন।

2021 সালে দুটি রিবিল্ড সামনে আসে। Rocky Linux শুরু করেছিলেন Gregory Kurtzer, যিনি CentOS-এর সহ-প্রতিষ্ঠাতা ছিলেন। AlmaLinux-এর অর্থায়ন করেছিল CloudLinux। জুন 2023-এ Red Hat তাদের RHEL সোর্সগুলো CentOS Stream এবং তাদের কাস্টমার পোর্টাল ছাড়া অন্য কোথাও প্রকাশ করা বন্ধ করে দেয়। Rocky হুবহু রিবিল্ডের লক্ষ্যেই অটল থাকে। AlmaLinux তাদের লক্ষ্য পরিবর্তন করে ABI (application binary interface) সামঞ্জস্যতার দিকে নিয়ে যায়, যার অর্থ হলো RHEL-এর জন্য তৈরি সফটওয়্যার সেখানে চলবে, তবে বাগ লিস্ট হুবহু মিলবে এমন কোনো নিশ্চয়তা নেই। Oracle, SUSE এবং CIQ সেই বছরের শেষের দিকে OpenELA গঠন করে যাতে শেয়ার করা সোর্সগুলো প্রকাশ করা যায়। 2003 সালের বিভাজন থেকে 2023 সালের সোর্স পরিবর্তনের ঘটনা এবং প্রতিটি রিবিল্ড এখন কী প্রতিশ্রুতি দেয়, তার পুরো ক্রমটি Red Hat, CentOS, Rocky এবং AlmaLinux-এর বিস্তারিত বিবরণে পাওয়া যাবে।

যদি কোনো প্রোভাইডারের ইমেজ লিস্টে এখনও CentOS লেখা থাকে, তবে সেটির ওপর ভিত্তি করে কিছু তৈরি করার আগে জেনে নিন তারা ঠিক কোনটি বোঝাচ্ছে।

cat /etc/os-release

NAME="CentOS Stream" হলো একটি রোলিং ডেভেলপমেন্ট শাখা যা RHEL-এর অগ্রগামী। NAME="AlmaLinux" অথবা NAME="Rocky Linux" হলো একটি রিবিল্ড যা সেটিকে অনুসরণ করে এবং দশ বছরের সাপোর্ট উইন্ডো প্রদান করে।

Ubuntu 20.04: ক্যালেন্ডারের পাতায় Debian unstable-এর একটি স্ন্যাপশট

Ubuntu 4.10 20 অক্টোবর 2004 সালে মুক্তি পায়, যার অর্থায়ন করেছিলেন Mark Shuttleworth। Debian-এর সাথে এর সম্পর্ক আবেগীয় নয়, বরং যান্ত্রিক। প্রতিটি রিলিজ সাইকেল শুরু হয় Debian unstable থেকে নতুন Ubuntu রিলিজের জন্য প্যাকেজ ইমপোর্ট করার মাধ্যমে। এই ইমপোর্ট প্রক্রিয়া সাইকেলের মাঝামাঝি সময় পর্যন্ত চলে, যাকে Debian Import Freeze বলা হয়। এরপর থেকে Ubuntu নিজস্ব পরিবর্তনগুলো বজায় রাখে। অনেক Ubuntu প্যাকেজ মূলত Debian প্যাকেজের সাথে একটি ডেল্টা (delta) যোগ করে তৈরি করা হয়, যা changelog-এ উল্লেখ থাকে।

এর অন্য অর্ধেক হলো ক্যালেন্ডার। Debian যখন প্রস্তুত হয় তখন মুক্তি পায়। Ubuntu মুক্তি পায় এপ্রিল এবং অক্টোবর মাসে, এবং ভার্সন নম্বরটি তারিখ অনুযায়ী নির্ধারিত হয়: 24.04 ভার্সনটি 2024 সালের এপ্রিলে মুক্তি পেয়েছে। প্রতি দ্বিতীয় এপ্রিলের রিলিজটি হলো LTS (long term support), যা কোনো প্রোভাইডার যখন কোনো অতিরিক্ত বিশেষণ ছাড়া Ubuntu তালিকাভুক্ত করে, তখন সেটিই বোঝায়। সার্ভারে এই দুটির মধ্যে কোনটি ব্যবহার করা উচিত তা Ubuntu LTS এবং ইন্টারিম রিলিজের মধ্যে নির্বাচন করার সম্পূর্ণ বিষয়, এবং এক LTS থেকে পরবর্তী LTS-এ যাওয়ার নিজস্ব পদ্ধতি রয়েছে, যা 24.04 থেকে 26.04 আপগ্রেড-এ আলোচনা করা হয়েছে।

একটি বিষয় প্রতি বছর সার্ভার অ্যাডমিনদের বিভ্রান্ত করে। Ubuntu-এর আর্কাইভ বিভিন্ন কম্পোনেন্টে বিভক্ত। main সম্পূর্ণ সাপোর্ট উইন্ডোর জন্য Canonical দ্বারা রক্ষণাবেক্ষণ করা হয়। universe কমিউনিটি দ্বারা রক্ষণাবেক্ষণ করা হয় এবং এর নিরাপত্তা কভারেজের প্রতিশ্রুতি ভিন্ন। apt install এই পার্থক্যের বিষয়ে কোনো তথ্য প্রদান করে না। একটি কমান্ডের মাধ্যমে এটি দেখা যায়:

apt-cache policy nginx

একটি রিপোজিটরি লাইনের শেষে /main থাকার অর্থ হলো প্যাকেজটির দায়িত্ব Canonical-এর নিরাপত্তা টিমের। লাইনের শেষে /universe থাকার অর্থ হলো এটি কমিউনিটি দ্বারা পরিচালিত। ইন্টারনেটের মুখোমুখি হয় এমন যেকোনো কিছুর জন্য এটি পরীক্ষা করে নিন।

Arch, 2002: রোলিং রিলিজ এবং আংশিক আপগ্রেডের ঝুঁকি

Judd Vinet 11 মার্চ 2002 সালে Arch 0.1 রিলিজ করেন। এতে ছিল তার নিজের লেখা একটি প্যাকেজ ম্যানেজার, pacman, এবং বিল্ড রেসিপি যা সাধারণ শেল স্ক্রিপ্ট। Arch-এ কোনো ভার্সনযুক্ত রিলিজ নেই। ইন্সটলেশন মিডিয়াগুলো হলো একই রোলিং রিপোজিটরির তারিখযুক্ত স্ন্যাপশট। তাই 2019 সালে ইন্সটল করা এবং প্রতি সপ্তাহে আপডেট হওয়া একটি মেশিনে ঠিক সেই Arch-ই চলে, যা আজ ইন্সটল করা মেশিনে চলছে। AUR (Arch user repository)-এ ব্যবহারকারীদের তৈরি বিল্ড রেসিপি থাকে। এগুলো কেবল রেসিপি, পরীক্ষিত প্যাকেজ নয়। তাই কোনো PKGBUILD চালানোর আগে তা পড়ে নেওয়া কাজের অংশ।

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

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

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

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

Alpine: একটি ছোট ডিস্ট্রিবিউশন যা কন্টেইনারের মাধ্যমে পরিচিতি পেয়েছে

Alpine 2005 সালের দিকে LEAF (Linux embedded appliance framework)-এর একটি fork হিসেবে যাত্রা শুরু করে, যা মূলত Linux Router Project থেকে উদ্ভূত। Natanael Copa এটিকে ডেস্কটপের পরিবর্তে অ্যাপ্লায়েন্সের জন্য তৈরি করেছিলেন। এটি প্রচলিত বেশিরভাগ userland-কে প্রতিস্থাপন করে: GNU C library-এর পরিবর্তে musl, GNU core utilities-এর পরিবর্তে BusyBox, systemd-এর পরিবর্তে OpenRC এবং প্যাকেজ ম্যানেজার হিসেবে apk ব্যবহার করে। 2014 সালে Alpine 3.0 রিলিজের মাধ্যমেই musl-এ স্থানান্তর সম্পন্ন হয়।

কন্টেইনার প্রযুক্তি এটিকে জনপ্রিয় করে তোলে। একটি Alpine base layer-এর আকার Debian বা Ubuntu-এর তুলনায় অনেক কম, তাই 2016 সাল থেকে এটি একটি সাধারণ base image হিসেবে ব্যবহৃত হতে থাকে। ফলে এমন অনেক মানুষ Alpine ব্যবহার করছেন যারা কখনোই এটি সরাসরি ইনস্টল করেননি।

এর অসুবিধা হলো, musl এবং glibc এক নয়, আর এই পার্থক্যের কারণে এমন সব বাগ দেখা দেয় যা দেখে মনে হয় এগুলোর সাথে কোনো সম্পর্ক নেই। glibc-এর সাথে লিঙ্ক করা কোনো binary Alpine-এ চললে এমন একটি error message দেয় যা দেখে মনে হয় ফাইলটি খুঁজে পাওয়া যাচ্ছে না, অথচ সেটি সেখানে উপস্থিত থাকে:

sh: ./myapp: not found

প্রোগ্রামটি বিদ্যমান। কিন্তু এর ELF interpreter খুঁজে পাওয়া যায় না, কারণ glibc-এর loader সেখানে অনুপস্থিত। Python-এর ক্ষেত্রেও একই ধরনের সমস্যা দেখা দেয়: manylinux-এর জন্য তৈরি prebuilt wheel ফাইলগুলো musl-এ ইনস্টল হয় না। ফলে pip সোর্স থেকে কম্পাইল করার চেষ্টা করে এবং কোনো কম্পাইলার না থাকলে তা ব্যর্থ হয়। 2021 সালের musllinux wheel স্ট্যান্ডার্ড এই সমস্যার সমাধান করেছে, তবে শুধুমাত্র সেইসব প্রজেক্টের জন্য যারা এই ফরম্যাটে wheel পাবলিশ করে।

একটি VPS-এ host operating system হিসেবে Alpine ইনস্টল করা সহজ এবং এটি দ্রুত আপডেট হয়। তবে এটি আপনাকে এমন একটি পথে নিয়ে যায় যা বেশিরভাগ ডকুমেন্টেশনে অনুসরণ করা হয় না। যে গাইডগুলো আপনাকে systemctl enable চালানোর পরামর্শ দেয়, সেগুলোকে Alpine-এর জন্য rc-update add হিসেবে অনুবাদ করে নিতে হয়।

ইমিউটেবল জেনারেশন: অ্যাটমিক আপডেট এবং ইমেজ-ভিত্তিক সার্ভার

নতুন এই শাখাটি প্যাকেজ তালিকার পরিবর্তে আপডেট মডেলকে পরিবর্তন করে। একটি ostree ভিত্তিক সিস্টেম /usr-কে read only হিসেবে রাখে। একটি আপডেট হলো সম্পূর্ণ নতুন একটি ফাইলসিস্টেম ট্রি, যা ডাউনলোড ও স্টেজ করা হয় এবং পরবর্তী রিবুটের সময় সেটিতে সুইচ করা হয়। পূর্ববর্তী ট্রিটি একটি বুট এন্ট্রি হিসেবে থেকে যায়, তাই কোনো ত্রুটিপূর্ণ আপডেট হলে পুরনোটিতে রিবুট করে সহজেই তা বাতিল করা যায়।

Fedora Silverblue 2018 সালে ডেস্কটপে এই সুবিধা নিয়ে আসে এবং Red Hat 2018 সালে CoreOS কিনে নেওয়ার পর 2019 সালে Fedora CoreOS এটি সার্ভারে নিয়ে আসে। 2020 সালে Container Linux বন্ধ হয়ে যাওয়ার পর Flatcar Container Linux মূল Container Linux-এর ধারাবাহিকতা বজায় রাখে। openSUSE MicroOS btrfs স্ন্যাপশট এবং transactional-update-এর মাধ্যমে একই অবস্থানে পৌঁছায়। 2024 সালে Red Hat RHEL-এ একটি ইমেজ-ভিত্তিক মোড যুক্ত করে, যা bootc-এর ওপর ভিত্তি করে তৈরি; এখানে অপারেটিং সিস্টেম একটি কন্টেইনার ইমেজ হিসেবে থাকে এবং নতুন কোনো ট্যাগের দিকে নির্দেশ করে মেশিন আপডেট করা হয়। Talos Linux সবচেয়ে এগিয়ে আছে এবং তারা শেল ও SSH সম্পূর্ণভাবে সরিয়ে ফেলেছে: মেশিনটি একটি API-এর মাধ্যমে কনফিগার করা হয়, তাই লগ ইন করার মতো কিছু অবশিষ্ট থাকে না। 2007 সালে প্রথম মুক্তি পাওয়া NixOS ভিন্ন একটি দিক থেকে আসে। পুরো সিস্টেমটি একটি ডিক্লারেটিভ কনফিগারেশন থেকে তৈরি হয় এবং পূর্ববর্তী জেনারেশনগুলো বুটযোগ্য অবস্থায় থাকে।

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

একটি রিলিজ কতদিন সাপোর্ট করা হয়?

রিলিজ পলিসি হলো কোনো ডিস্ট্রিবিউশনের সেই অংশ যা আপনার সাথে দীর্ঘ সময় থাকে এবং এটি বছরের হিসেবে প্রকাশিত হয়। এখানে 5 টি বর্তমান সার্ভার রিলিজের সময়সীমা দেওয়া হলো।

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine প্রতিটি 3.x ব্রাঞ্চকে 2 বছর সাপোর্ট করে। এই কারণেই এটি এমন কন্টেইনার ইমেজের জন্য উপযুক্ত যা আপনি ঘনঘন রিবিল্ড করেন, কিন্তু এমন হোস্টের জন্য নয় যা আপনি দীর্ঘ সময় পরিবর্তনহীন রাখেন। Debian-এর সিকিউরিটি টিম একটি স্টেবল রিলিজকে প্রায় 3 বছর পর্যন্ত সাপোর্ট দেয় এবং এরপর LTS টিম সাধারণ আর্কিটেকচারগুলোর জন্য মোট প্রায় 5 বছর পর্যন্ত সাপোর্ট প্রদান করে। Ubuntu LTS আপনাকে main-এর প্যাকেজগুলোর জন্য 5 বছর সাপোর্ট দেয় এবং একটি Ubuntu Pro সাবস্ক্রিপশন এটিকে 10 বছর পর্যন্ত বাড়িয়ে দেয়, যা ব্যক্তিগত ব্যবহারের জন্য অল্প সংখ্যক মেশিনে বিনামূল্যে পাওয়া যায়। RHEL 10 10 বছরের সাপোর্ট ঘোষণা করে, যা পেইড এক্সটেন্ডেড লাইফ সাইকেল সাপোর্ট অ্যাড-অন ব্যবহার করে 13 বছর পর্যন্ত বাড়ানো সম্ভব। AlmaLinux 10 কোনো সাবস্ক্রিপশন ছাড়াই RHEL-এর 10 বছরের সময়সীমা অনুসরণ করে, আর এই কারণেই এই রিবিল্ডগুলোর অস্তিত্ব রয়েছে।

Arch-এর ক্ষেত্রে এখানে কোনো সারি নেই, কারণ একটি রোলিং ডিস্ট্রিবিউশনের সাপোর্ট করার মতো কোনো নির্দিষ্ট রিলিজ থাকে না। Arch-এর ক্ষেত্রে গুরুত্বপূর্ণ বিষয় হলো আপনি একটি মেশিনকে কতদিন কোনো পরিবর্তন ছাড়া ফেলে রাখতে পারেন, যা সপ্তাহের হিসেবে পরিমাপ করা হয়।

আপনার VPS ইমেজ লিস্ট কেন এমন দেখায়

একটি প্রোভাইডার গ্রাহকদের চাহিদা অনুযায়ী ইমেজ সরবরাহ করে, যা তাদের হাইপারভাইজারে স্বয়ংক্রিয়ভাবে ইনস্টল হয়। এই কারণেই প্রায় প্রতিটি তালিকার শুরুতে Ubuntu LTS এবং Debian stable থাকে, RHEL-এর সাথে সার্টিফাইড সফটওয়্যার ব্যবহারকারীদের জন্য AlmaLinux বা Rocky যোগ করা হয় এবং Alpine, Arch ও Fedora-কে তালিকার নিচের দিকে রাখা হয়। একবার আপনি যদি VPS কী এবং ইমেজ কীভাবে ডিস্কে পৌঁছায় তা জেনে যান, তবে এই প্যাটার্নটি পরিষ্কার হয়ে যায়: প্রোভাইডার এমন অপারেটিং সিস্টেম বেছে নেয় যা স্বয়ংক্রিয় ইনস্টলেশনে টিকে থাকে এবং গড় গ্রাহকের সার্ভার ব্যবহারের সময়ের চেয়ে বেশি সময় ধরে সাপোর্ট পায়।

এই পছন্দটি আপনাকে কেবল একটি প্যাকেজ ম্যানেজারের চেয়েও বেশি কিছুর সাথে যুক্ত করে। এটি নির্ধারণ করে তিন বছর পর আপনি কোন আপগ্রেডটি চালাবেন, এবং এই প্রক্রিয়াটি অপারেটিং সিস্টেমের ফ্যামিলি অনুযায়ী সম্পূর্ণ ভিন্ন হয়। Debian এবং Ubuntu সরাসরি ইন-প্লেস মেজর আপগ্রেড সাপোর্ট করে। Red Hat ফ্যামিলি leapp-এর মাধ্যমে এটি পরিচালনা করে। Arch-এর কোনো আপগ্রেড নেই কারণ এর কোনো নির্দিষ্ট ভার্সন নেই। Alpine-এর ক্ষেত্রে /etc/apk/repositories এডিট করে apk upgrade --available চালাতে হয়। এই পছন্দটি আরও নির্ধারণ করে যে, কোনো থার্ড-পার্টি রিপোজিটরি যোগ না করেই আপনি কোন সফটওয়্যার ইনস্টল করতে পারবেন, আপনার ব্যবহৃত কোনো সফটওয়্যারে CVE (common vulnerabilities and exposures) ধরা পড়লে কে প্যাচ সরবরাহ করবে এবং আপনার ভবিষ্যতের সফটওয়্যার কোন init system ও C library-কে উপস্থিত বলে ধরে নেবে।

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

FAQ

আমার সার্ভারটি কোন Linux ডিস্ট্রিবিউশন ফ্যামিলির অন্তর্ভুক্ত?

cat /etc/os-release কমান্ডটি চালান। ID ফিল্ডে ডিস্ট্রিবিউশনের নাম এবং ID_LIKE ফিল্ডে তার ফ্যামিলির নাম থাকে। যেমন, একটি Ubuntu মেশিন ID_LIKE=debian এবং একটি AlmaLinux মেশিন ID_LIKE="rhel centos fedora" রিপোর্ট করে। প্যাকেজ ম্যানেজার দেখেও এটি বোঝা যায়। apt এবং dpkg মানে হলো Debian ফ্যামিলি, dnf এবং rpm মানে হলো Red Hat ফ্যামিলি, apk মানে Alpine এবং pacman মানে Arch।

CentOS কি এখনও RHEL-এর একটি ফ্রি সংস্করণ?

না। CentOS Linux 8 ছিল এই নামের শেষ রিবিল্ড, যার মেয়াদ 31 ডিসেম্বর 2021 তারিখে শেষ হয়েছে এবং CentOS Linux 7-এর মেয়াদ 30 জুন 2024 তারিখে শেষ হয়েছে। বর্তমানে টিকে থাকা প্রজেক্ট, CentOS Stream, হলো সেই শাখা যেখান থেকে RHEL-এর মাইনর রিলিজগুলো তৈরি হয়; তাই এতে RHEL-এর আগে পরিবর্তন আসে, পরে নয়। পুরনো CentOS-এর ভূমিকা এখন AlmaLinux এবং Rocky Linux পালন করছে, যার প্রতিটিরই দশ বছরের সাপোর্ট উইন্ডো রয়েছে।

Debian stable-এ কেন এত পুরনো ভার্সন নম্বর থাকে?

কারণ ভার্সন নম্বরটি স্থির থাকে কিন্তু ফিক্সগুলো নিয়মিত আসতে থাকে। Debian নতুন কোনো আপস্ট্রিম রিলিজ ইমপোর্ট করার পরিবর্তে তাদের রিলিজ করা ভার্সনেই সিকিউরিটি প্যাচগুলো ব্যাকপোর্ট করে। তাই যে প্যাকেজের ভার্সন 2.4.57-2+deb13u1 দেখাচ্ছে, তাতেও গত সপ্তাহে প্রকাশিত কোনো সিকিউরিটি ফিক্স থাকতে পারে। আপস্ট্রিম ভার্সনের পরের সাফিক্সটি হলো Debian রিভিশন, এবং apt changelog <package> কমান্ডটি দিয়ে দেখা যায় এতে কী কী পরিবর্তন আনা হয়েছে। ভার্সন নম্বর দেখে Debian সার্ভারের নিরাপত্তা যাচাই করা সবসময় ভুল ফলাফল দেয়।

VPS-এ কি Arch-এর মতো রোলিং রিলিজ ব্যবহার করা উচিত?

শুধুমাত্র যদি আপনি নিয়মিত আপডেট করার সময়সূচী মেনে চলেন তবেই এটি ব্যবহার করুন। একটি রোলিং ডিস্ট্রিবিউশন ধরে নেয় যে প্রতিটি মেশিন বর্তমান প্যাকেজ সেটের সাথে সামঞ্জস্যপূর্ণ থাকবে। তাই pacman -Sy foo দিয়ে একটি প্যাকেজ আপডেট করলে লাইব্রেরির অমিল দেখা দিতে পারে এবং cannot open shared object file-এর মতো এরর আসতে পারে। নিয়মিত pacman -Syu চালান এবং প্রতিটি আপডেটের আগে প্রজেক্টের নিউজ পেজটি পড়ুন, তাহলেই সিস্টেমটি স্থিতিশীল থাকবে। এক বছর আপডেট না করলে প্রথমবার আপগ্রেড করার সময় ঝুঁকি তৈরি হতে পারে।

ইমিউটেবল (immutable) বা অ্যাটমিক (atomic) ডিস্ট্রিবিউশন আসলে কী পরিবর্তন করে?

এটি আপডেট প্রয়োগের সময় এবং তা বাতিল করার পদ্ধতি পরিবর্তন করে। /usr ফাইলসিস্টেমটি রিড-অনলি হিসেবে মাউন্ট করা থাকে। আপডেট একটি সম্পূর্ণ নতুন ট্রি (tree) হিসেবে তৈরি হয় এবং রিবুট করার সময় সুইচ করা হয়, যেখানে আগের ট্রি-টি রোলব্যাকের জন্য একটি বুট এন্ট্রি হিসেবে থেকে যায়। এতে আপনি এমন একটি মেশিন পান যা হয় পুরোপুরি আপডেট করা, অথবা আপডেট করা হয়নি—মাঝামাঝি কোনো অবস্থা থাকে না। ফাইল এডিট করে সফটওয়্যার ইনস্টল করার সুবিধা এখানে থাকে না, তাই অ্যাপ্লিকেশনগুলোকে কন্টেইনারে অথবা লেয়ারড প্যাকেজে স্থানান্তর করতে হয়।