Fedora VPS সার্ভারে 13 মাস পর কী করতে হবে?

একটি Fedora রিলিজ কত দিন নিরাপত্তা আপডেট পায়?

একটি Fedora সার্ভারে মেশিনটি চালু থাকা পর্যন্ত প্রায় বছরে একবার version upgrade করতে হয়। Fedora প্রায় প্রতি ছয় মাসে একটি নতুন release প্রকাশ করে। প্রতিটি release-এর support থাকে তার দুই version পরের release প্রকাশের প্রায় চার সপ্তাহ পর্যন্ত। ফলে এটি প্রায় 13 মাসের update support-এর সমান। ওই তারিখের পর release-টির জন্য আর কোনো security fix প্রকাশ করা হয় না। সার্ভারটি চলতে থাকে, কিন্তু এর package set আর কেউ patch করে না।

তারিখগুলো দেখলে বিষয়টি স্পষ্ট হয়। August 2026 অনুযায়ী supported release হলো Fedora 43 এবং Fedora 44। Fedora 44 28 April 2026-এ প্রকাশিত হয়েছে এবং এর end of life June 2027-এ নির্ধারিত। Fedora 42 April 2025-এ প্রকাশিত হয়েছিল এবং May 2026-এ end of life-এ পৌঁছেছে, Fedora 44 প্রকাশের চার সপ্তাহ পরে। তাই Fedora 42 image দিয়ে তৈরি একটি সার্ভার তেরো মাস পরে support-এর বাইরে চলে যায়, কেউ কোনো ভুল না করলেও।

Fedora বনাম LTS: মাসের হিসাবে

LTS-এর অর্থ long term support: এমন একটি release, যেটি vendor কয়েক মাসের বদলে বছরের পর বছর patch করে। EOL-এর অর্থ end of life: যে তারিখে patch দেওয়া বন্ধ হয়। আজ আপনি যে release install করবেন, প্রতিটি project তার জন্য নিচের তথ্য প্রকাশ করে।

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

প্রতিটি release-এর জন্য Fedora আপনাকে 13 মাসের support দেয়। একটি Ubuntu LTS দেয় 60, আর AlmaLinux-এর মতো একটি enterprise rebuild দেয় 120। দ্বিতীয় কলামটিকে কাজের হিসাব হিসেবে দেখুন। দশ বছরে Fedora-তে পুরো operating system প্রায় 10 বার upgrade করতে হয়, যেখানে Ubuntu LTS-এ লাগে 2 বার। Debian-এর 36 মাস হলো এর নিয়মিত security support-এর সময়কাল; আলাদা একটি LTS team অধিকাংশ release-এর support প্রায় পাঁচ বছর পর্যন্ত বাড়ায়।

এগুলো August 2026-এ যাচাই করা প্রকাশিত support window; measured uptime নয়। এই cadence-গুলো কেন আলাদা, তা server-এ Ubuntu LTS এবং interim release-এর পার্থক্য-এ ব্যাখ্যা করা হয়েছে। এখানে গুরুত্বপূর্ণ হলো, প্রতিটি option আপনার জন্য কতটা কাজ তৈরি করে।

Fedora version upgrade-এ আসলে কী ঘটে

Fedora 41 থেকে DNF 5 ডিফল্ট package manager, এবং dnf এটি চালায়। system-upgrade command-টি dnf5-এরই অংশ, তাই আগে কোনো plugin install করতে হয় না। বর্তমান release থেকে শুরু করুন এবং সিস্টেম সম্পূর্ণভাবে patch করা আছে কি না নিশ্চিত করুন:

sudo dnf upgrade --refresh
sudo reboot

Reboot করা গুরুত্বপূর্ণ। কারণ upgrade বর্তমানে install করা এবং চালু থাকা উপাদানগুলোর ভিত্তিতে resolve হয়। তাই kernel বা glibc update আংশিকভাবে প্রয়োগ হলে পরের ধাপের সমস্যা বিশ্লেষণ করা কঠিন হয়। এবার নতুন release প্রস্তুত করুন। যে release-এ upgrade করবেন, 44-এর জায়গায় সেই release number বসান:

sudo dnf system-upgrade download --releasever=44

এটি সম্পূর্ণ transaction resolve করে এবং প্রতিটি package download করে, কিন্তু চলমান সিস্টেমে কোনো পরিবর্তন করে না। একটি ছোট server-এ কয়েক হাজার package এবং এক থেকে তিন gigabyte download হওয়ার জন্য প্রস্তুত থাকুন। dnf transaction resolve করতে না পারলে এখানেই থেমে যায় এবং কোন package সমস্যাটি ঘটিয়েছে তা জানায়। এটিই ভালো পরিস্থিতি, কারণ machine তখনও চালু থাকে এবং আপনার shell access থাকে।

এবার এটি চালান:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status নিশ্চিত করে যে একটি transaction প্রস্তুত হয়ে অপেক্ষা করছে। dnf system-upgrade reboot machine-টি offline transaction-এর জন্য restart করে। এটি একটি minimal boot, যেখানে RPM transaction স্বয়ংক্রিয়ভাবে চলে। কারণ চলমান service-এর নিচে glibc এবং systemd প্রতিস্থাপন করলে system আংশিকভাবে install হওয়া অবস্থায় পড়ে যেতে পারে। সম্পূর্ণ transaction চলাকালে আপনার server unreachable থাকবে। একটি ছোট VPS-এ এটি সাধারণত কয়েক মিনিট স্থায়ী হয়। এরপর machine আবার নতুন release-এ reboot হয়। দুটি reboot এবং এমন একটি সময়ের জন্য প্রস্তুতি নিন, যখন SSH কোনো উত্তর দেবে না।

Machine ফিরে এলে:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release-এ Fedora release 44 (Forty Four)-এর মতো একটি line দেখা উচিত। log subcommand ওই offline boot-এর transaction log দেখায়। Shell access না থাকা অবস্থায় কী ঘটেছে, তার একমাত্র record এটিই। distro-sync নতুন release-এর version অনুযায়ী অবশিষ্ট package update করে। repoquery --extras এমন installed package-এর তালিকা দেখায়, যেগুলো এখন আর কোনো enabled repository-তে নেই। নতুন release-এর জন্য কখনো প্রকাশিত হয়নি এমন repository-এর leftover সাধারণত এখানেই পাওয়া যায়।

Download ধাপের আগে disk snapshot নিন। Transaction চলার সময় আপনি screen দেখতে পারবেন না। তাই offline boot-এ এটি ব্যর্থ হলে SSH আর ফিরে নাও আসতে পারে। তখন provider-এর দেওয়া console, VNC বা serial access-ই machine-এ প্রবেশের একমাত্র উপায় হতে পারে। শুরু করার আগে নিশ্চিত করুন যে আপনার console access বা snapshot আছে, ব্যর্থতার পরে নয়।

আরেকটি পরীক্ষা আছে, যা অনেকে বাদ দেন:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

কোনো package নতুন default config file প্রকাশ করলে এবং আপনি পুরোনো file-টি সম্পাদনা করে থাকলে, RPM আপনার file overwrite করে না। এটি packaged version-টি .rpmnew নামে পাশাপাশি লিখে রাখে। ফলে আপনার sshd বা nginx পুরোনো release-এর মতোই কাজ করতে থাকে, আর নতুন default disk-এ পড়ে থাকে। প্রতিটি upgrade-এর পরে এই file-গুলো পড়ুন। rpmconf install করে sudo rpmconf -a চালালে file-গুলো একে একে পরীক্ষা করা যায় এবং পার্থক্য দেখা যায়।

তৃতীয় পক্ষের repository-গুলোই upgrade আটকে দেয়

Fedora-এর নিজস্ব package-গুলো release-এর দিনে একসঙ্গে এগিয়ে যায়। Fedora-এর বাইরের যেকোনো কিছু অন্য কারও schedule অনুযায়ী প্রকাশিত হয়। বেশিরভাগ vendor repository তাদের URL-এ $releasever ব্যবহার করে। তাই upgrade করার সঙ্গে সঙ্গে dnf এমন একটি path চাইতে শুরু করে, যা তখনও তৈরি নাও হতে পারে।

আপনার configured repository-গুলোর তালিকা দেখুন:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Fedora-এর নিজস্ব নয়—এমন প্রতিটি repository target release-এর সঙ্গে পরীক্ষা করুন। কোনো পরিবর্তন স্থায়ীভাবে প্রয়োগ করার আগে এই পরীক্ষা করুন:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Vendor ওই release-এর জন্য package প্রকাশ করে থাকলে dnf metadata download করে এবং কোনো error ছাড়াই বন্ধ হয়। না হলে https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml-এর মতো path-এর জন্য 404 দেখাবে। একই failure পরে system-upgrade download-এও upgrade থামিয়ে দেবে। Fedora release-এর পরের প্রথম কয়েক সপ্তাহে upgrade শুরু না হওয়ার সবচেয়ে সাধারণ কারণ এটিই।

এ ক্ষেত্রে আপনার দুটি পথ আছে। Vendor প্রকাশ না করা পর্যন্ত কয়েক সপ্তাহ অপেক্ষা করুন। সাধারণত এটাই সঠিক সিদ্ধান্ত। অথবা ওই repository বাদ দিয়ে upgrade করুন:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

কোনো repository disable করলে তার package মুছে যায় না। সেগুলো installed এবং unmanaged অবস্থায় থাকে। ওই package-গুলো transaction আটকে দিলে dnf তা জানায়। --allowerasing যোগ করলে dnf conflict সমাধানের জন্য installed package মুছে ফেলতে পারে। তাই accept করার আগে removal list পড়ে নিন। এই তালিকাতেই এমন database server হারিয়ে যেতে পারে, যা আপনি রেখে দিতে চেয়েছিলেন।

একটি Fedora server নির্ধারিত সময়সীমা পার করলে কী হয়

সেই দিন নিজে কিছুই ঘটে না। আপনি পরের বার package manager ব্যবহার করলে সমস্যা দেখা দেয়। End-of-life release-গুলো mirror network থেকে সরিয়ে archive-এ রাখা হয়। তাই dnf upgrade metadata সংগ্রহের সময় ব্যর্থ হয় এবং আপনার release-এর metalink URL-এ 404 দেখায়:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

মেশিনটি network traffic পরিবেশন করতে থাকে। এ কারণেই বিষয়টি নীরব হলেও বিপজ্জনক। এটি আর security update পায় না। কিছু install-ও করা যায় না। ফলে OpenSSH বা nginx-এর কোনো security advisory প্রকাশের দিন আপনি এটি patch করার জন্য কোনো supported উপায় পান না।

সমস্যা থেকে বের হওয়া সম্ভব, তবে সময় লাগে। আপনি repository-গুলোকে https://dl.fedoraproject.org/pub/archive/fedora/linux/-এ থাকা Fedora archive-এর দিকে নির্দেশ করে সেখান থেকে upgrade করতে পারেন। Fedora সাধারণত একবারে এক বা দুইটি release পার হওয়ার পরামর্শ দেয়। তাই চারটি release পিছিয়ে থাকা একটি server-কে পরপর কয়েকটি hop পার হতে হয়। প্রতিটি ধাপে ব্যর্থতার সম্ভাবনা থাকে। প্রতিটি ধাপে offline boot-এর সময় পর্যবেক্ষণ সীমিত থাকে। VPS হলে current image দিয়ে নতুন করে তৈরি করে data স্থানান্তর করা সাধারণত কম সময়সাপেক্ষ এবং নিরাপদ। এটি নতুন VPS-এ প্রথম দশ মিনিটের কাজের সমতুল্য।

Automatic updates একটি release-এ patch প্রয়োগ করে। এগুলো কখনও release upgrade করে না।

Fedora timer ব্যবহার করে update ইনস্টল করতে পারে:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Settings থাকে /etc/dnf/automatic.conf-এ। এটি /usr/share/dnf5/dnf5-plugins/automatic.conf-এ থাকা shipped default-কে override করে। apply_updates ডিফল্টভাবে বন্ধ থাকে। তাই out of the box timer update download করে, কিন্তু কিছু ইনস্টল করে না। upgrade_type, default এবং security-এর মধ্যে নির্বাচন করে। reboot, never, when-changed অথবা when-needed গ্রহণ করে।

এতে একই release-এর মধ্যে সিস্টেম আপডেট থাকে। এটি কখনও Fedora 43-কে Fedora 44-এ উন্নীত করবে না। কারণ version upgrade একটি আলাদা এবং ইচ্ছাকৃত কাজ, যেখানে offline transaction চালানোর জন্য সিস্টেম reboot হয়। LTS-এর তুলনায় এটাই ব্যবহারিক সীমাবদ্ধতা। Ubuntu-তে, unattended security upgrade কোনো version change ছাড়াই পুরো পাঁচ বছরের সময়সীমা জুড়ে মেশিনকে আপডেট রাখে। Version change নিজেই কয়েক বছর পরপর পরিকল্পিত কাজ হিসেবে করা হয়, যেমন 24.04 থেকে 26.04-এ upgrade।

যখন server চালানোর জন্য Fedora উপযুক্ত

Fedora উপযুক্ত, যখন নতুনত্বই মূল প্রয়োজন।

• আপনার এমন kernel বা userspace দরকার, যা যেকোনো LTS release-এ আসা সংস্করণের চেয়ে নতুন: যেমন সাম্প্রতিক hardware, অথবা এমন container ও systemd stack, যা enterprise release-এ আসতে এখনও এক বছর বাকি। একটি release চলাকালেও Fedora নতুন upstream kernel-এ চলে যায়। তাই এই সুবিধা শুধু install করার সময় একবার পাওয়া যায় না।
• আপনি RHEL (Red Hat Enterprise Linux)-এ আসন্ন পরিবর্তন যাচাই করছেন। Fedora, CentOS Stream-এ software সরবরাহ করে, আর CentOS Stream, RHEL-এ software সরবরাহ করে। তাই আজ Fedora-তে build ও run করা software কয়েক বছর পরের enterprise platform-এর বিপরীতে পরীক্ষা করা হচ্ছে।
• মেশিনটি পরিকল্পনা অনুযায়ী অল্প সময়ের জন্য ব্যবহৃত হবে। দুই মাস পর ধ্বংস করা build runner বা test box কখনও তার end-of-life তারিখে পৌঁছায় না। একই যুক্তি coding agent-দের দেওয়া disposable VM-এর ক্ষেত্রেও প্রযোজ্য, কারণ Fedora release হওয়ার চেয়ে অনেক বেশি ঘন ঘন সেই box পুনর্নির্মাণ করা হয়।
• Upgrade-এর দায়িত্ব কারও নির্দিষ্টভাবে রয়েছে। নির্দিষ্ট owner এবং calendar entry থাকা server-এ Fedora ব্যবহার করা যায়। কিন্তু যে box-এর দায়িত্ব সবাই ভুলে গেছে, তার জন্য Fedora উপযুক্ত নয়।

মাঝামাঝি পথ: স্থিতিশীল ভিত্তিতে বর্তমান package

সার্ভারে Fedora ব্যবহার করতে চান এমন অধিকাংশ মানুষের দরকার দুই বা তিনটি বর্তমান package, সম্পূর্ণ বর্তমান operating system নয়। এই দুটিকে আলাদা রাখা যায়। ভিত্তি হিসেবে একটি LTS বা enterprise rebuild চালান। এরপর যেখানে সত্যিই প্রয়োজন, সেখানে নতুন software যুক্ত করুন। একটি container image এমন host-এর ওপর application-এর নতুন version দেয়, যার জন্য host upgrade করতে হয় না (VPS-এ Docker চালানো)। PostgreSQL বা nginx-এর মতো আপনার প্রয়োজনীয় একটি package-এর জন্য vendor repository ব্যবহার করলে শুধু সেই package-টি আপডেট হয় এবং base অপরিবর্তিত থাকে।

এই বিনিময়ের উভয় দিকই স্পষ্ট। Container host-এর পুরোনো kernel-এর ওপর নতুন userspace দেয়। তাই kernel-ই আপডেট করার প্রয়োজন হলে container কোনো সমাধান নয়। Vendor repository এমন base-এর ওপর একটি নতুন package দেয়, যা vendor কম পরীক্ষা করেছে। উভয় ক্ষেত্রেই base system-এর security update LTS-এর সময়সূচি অনুসরণ করে। Fedora-তে প্রতি বছর যে maintenance window দরকার হয়, মূল খরচটি এই সময়সূচির কারণেই।

সার্ভারের জন্য Fedora বেছে নিলে release cycle-টি calendar-এ লিখে রাখুন। কোনো release প্রকাশিত হলে vendor repository-গুলো আপডেট হওয়ার জন্য কয়েক সপ্তাহ অপেক্ষা করুন। তারপর snapshot নিন, upgrade করুন এবং service-গুলো পুনরায় চালু হয়েছে কি না যাচাই করুন। এই পদ্ধতিতে বছরে প্রায় এক ঘণ্টা সময় লাগে এবং এটি কার্যকর। যে সংস্করণটি ব্যর্থ হয়, সেটি হলো এমন upgrade, যার কথা শুধু তখনই মনে পড়ে যখন ইতিমধ্যে কোনো কিছু নষ্ট হয়ে গেছে।

FAQ

Fedora-এর একটি release কতদিন support পায়?

প্রায় 13 মাস। Fedora প্রায় প্রতি ছয় মাসে একটি release প্রকাশ করে এবং দুই সংস্করণ পরের release প্রকাশের প্রায় চার সপ্তাহ পর পর্যন্ত প্রতিটি release support করে। Fedora 44 28 April 2026-এ প্রকাশিত হয়েছিল এবং এর end of life June 2027-এ নির্ধারিত। এই তারিখ পার হলে release-টি আর security update পায় না এবং এর package-গুলো mirror থেকে সরিয়ে Fedora-এর archive-এ রাখা হয়।

আমি কি একটি Fedora release বাদ দিয়ে একসঙ্গে দুই সংস্করণ upgrade করতে পারি?

হ্যাঁ, কিছু সীমার মধ্যে। dnf system-upgrade download --releasever= target হিসেবে এক বা দুই release পরের সংস্করণ গ্রহণ করে, এবং বছরে একবার upgrade করার পদ্ধতিতে একসঙ্গে দুই সংস্করণ এগিয়ে যাওয়াই স্বাভাবিক। এর চেয়ে বেশি এগিয়ে যাওয়া supported path নয়। প্রতিটি অতিরিক্ত release-এ package rename বা config format পরিবর্তনের কারণে transaction ব্যর্থ হওয়ার ঝুঁকি বাড়ে। কোনো machine ইতিমধ্যে কয়েকটি release পিছিয়ে থাকলে এবং end of life পার হয়ে গেলে, একাধিক ধাপে upgrade করার চেয়ে current image দিয়ে server rebuild করা সাধারণত দ্রুত।

আমার Fedora server end of life-এ পৌঁছালে কী হয়?

Server চলতে থাকে, কিন্তু patch পাওয়া বন্ধ করে। পরবর্তী dnf upgrade আপনার release-এর metalink URL-এ 404 error দেখিয়ে ব্যর্থ হয়, কারণ end of life release-গুলো dl.fedoraproject.org-এ archive-এ সরিয়ে নেওয়া হয়। আপনি repository file-গুলো ওই archive-এ নির্দেশ করে ধাপে ধাপে upgrade করতে পারেন, অথবা supported release দিয়ে server rebuild করতে পারেন। এই দুটির কোনো একটি না করা পর্যন্ত machine-এ কোনো security update পৌঁছাবে না এবং কোনো package install হবে না।

Production server-এর জন্য Fedora কি খারাপ পছন্দ?

এটি একটি খারাপ default choice, তবে নির্দিষ্ট কারণ থাকলে যুক্তিসঙ্গত পছন্দ। এর খরচ হলো প্রতি বছর একটি সম্পূর্ণ operating system upgrade করা, এবং এটি অনির্দিষ্টকাল চালিয়ে যাওয়া—এমন একটি machine-এ যেটি আপনি হয়তো পরিবর্তন করতে চান না। LTS release-এ থাকা kernel বা userspace-এর চেয়ে নতুন সংস্করণ প্রয়োজন হলে, অথবা server-টি পরিকল্পনা অনুযায়ী স্বল্পমেয়াদি হলে Fedora বেছে নিন। বহু বছর version পরিবর্তন না করে server patch করতে চাইলে LTS বা enterprise rebuild বেছে নিন।