Fedora সার্ভার আপডেট করার নিয়ম ও সময়সীমা

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

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

তারিখগুলো দেখলে বিষয়টি স্পষ্ট হয়। আগস্ট 2026 অনুযায়ী, সমর্থিত রিলিজগুলো হলো Fedora 43 এবং Fedora 44। Fedora 44 রিলিজ হয়েছে 28 এপ্রিল 2026 তারিখে এবং এর মেয়াদ শেষ হওয়ার কথা জুন 2027-এ। Fedora 42 রিলিজ হয়েছিল এপ্রিল 2025-এ এবং এর মেয়াদ শেষ হয়েছে মে 2026-এ, যা Fedora 44 আসার চার সপ্তাহ পরের ঘটনা। সুতরাং, Fedora 42 ইমেজ থেকে তৈরি একটি সার্ভার কোনো ভুল ছাড়াই তেরো মাস পর সাপোর্ট হারায়।

Fedora বনাম LTS, মাস হিসেবে

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

[
  {
    "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
  }
]

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

এগুলো হলো প্রকাশিত সাপোর্ট উইন্ডো, যা আগস্ট 2026-এ যাচাই করা হয়েছে, এটি কোনো পরিমাপকৃত uptime নয়। কেন এই cadence বা গতির ভিন্নতা হয়, তা সার্ভারে Ubuntu LTS এবং interim release-এর মধ্যে পার্থক্য অংশে আলোচনা করা হয়েছে। এখানে গুরুত্বপূর্ণ বিষয় হলো, প্রতিটি সিস্টেম আপনার জন্য কী পরিমাণ কাজের চাপ তৈরি করে।

Fedora ভার্সন আপগ্রেড আসলে যা যা অন্তর্ভুক্ত করে

Fedora 41 থেকে DNF 5 ডিফল্ট প্যাকেজ ম্যানেজার হিসেবে ব্যবহৃত হচ্ছে এবং dnf এটি পরিচালনা করে। system-upgrade কমান্ডটি সরাসরি dnf5-এর অংশ, তাই আগে থেকে কোনো প্লাগইন ইনস্টল করার প্রয়োজন নেই। আপনি যদি Debian বা Ubuntu থেকে এসে থাকেন, তবে আপনার দৈনন্দিন কাজের বেশিরভাগ কমান্ডের সরাসরি apt থেকে dnf সমতুল্য কমান্ড রয়েছে, তবে নিচের ভার্সন আপগ্রেড প্রক্রিয়াটি এমন একটি কাজ যার কোনো প্রকৃত সমতুল্য নেই। বর্তমান রিলিজ থেকে শুরু করুন এবং সব প্যাচ আপডেট করে নিন:

sudo dnf upgrade --refresh
sudo reboot

রিবুট করা জরুরি কারণ আপগ্রেডটি বর্তমানে ইনস্টল করা এবং চলমান প্যাকেজগুলোর ওপর ভিত্তি করে সম্পন্ন হয়, তাই অসম্পূর্ণ kernel বা glibc আপডেট পরবর্তী ধাপের সমস্যাগুলো বিশ্লেষণ করা কঠিন করে তোলে। এখন নতুন রিলিজটি স্টেজ করুন। 44-এর জায়গায় আপনি যে রিলিজে যেতে চান সেটি লিখুন:

sudo dnf system-upgrade download --releasever=44

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

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

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status নিশ্চিত করে যে একটি ট্রানজ্যাকশন স্টেজ করা হয়েছে এবং অপেক্ষায় আছে। dnf system-upgrade reboot মেশিনটিকে একটি অফলাইন ট্রানজ্যাকশনে রিবুট করে: এটি একটি মিনিমাল বুট যেখানে RPM ট্রানজ্যাকশন নিজে থেকে চলে। এটি এভাবেই কাজ করে কারণ চলমান সার্ভিসের নিচে glibc এবং systemd প্রতিস্থাপন করলে সিস্টেম অসম্পূর্ণভাবে ইনস্টল হতে পারে। পুরো ট্রানজ্যাকশন চলাকালীন আপনার সার্ভারটি রিচ করা যাবে না, সাধারণত ছোট VPS-এর ক্ষেত্রে কয়েক মিনিট সময় লাগে, এরপর এটি নতুন রিলিজে আবার রিবুট হয়। দুটি রিবুট এবং SSH সংযোগ বিচ্ছিন্ন থাকার সময়ের জন্য পরিকল্পনা রাখুন।

সার্ভার ফিরে আসার পর:

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)-এর মতো একটি লাইন থাকা উচিত। log সাবকমান্ডটি অফলাইন বুটের ট্রানজ্যাকশন লগ প্রিন্ট করে, যা আপনার শেল না থাকা অবস্থায় কী ঘটেছে তার একমাত্র রেকর্ড। distro-sync নতুন রিলিজের ভার্সনে বাকি থাকা যেকোনো কিছু আপডেট করে। repoquery --extras এমন ইনস্টল করা প্যাকেজগুলোর তালিকা দেয় যা আর কোনো এনাবল করা রিপোজিটরিতে নেই, এখান থেকেই আপনি এমন প্যাকেজগুলো খুঁজে পাবেন যেগুলোর রিপোজিটরি নতুন রিলিজের জন্য আর প্রকাশিত হয়নি।

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

আরেকটি চেক যা অনেকে এড়িয়ে যায়:

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

যখন কোনো প্যাকেজ নতুন ডিফল্ট কনফিগারেশন ফাইল নিয়ে আসে এবং আপনি পুরনোটি এডিট করে থাকেন, তখন RPM আপনার ফাইলটি ওভাররাইট করে না। এটি প্যাকেজ করা ভার্সনটিকে .rpmnew হিসেবে পাশে রেখে দেয়। ফলে আপনার sshd বা nginx পুরনো রিলিজের মতোই কাজ করতে থাকে, আর নতুন ডিফল্ট সেটিংসগুলো ডিস্কে অব্যবহৃত অবস্থায় পড়ে থাকে। প্রতিটি আপগ্রেডের পর এই ফাইলগুলো পড়ুন। rpmconf ইনস্টল করে sudo rpmconf -a চালালে আপনি ফাইলগুলো একটি একটি করে দেখতে পারবেন এবং পার্থক্যগুলো বুঝতে পারবেন।

থার্ড-পার্টি রিপোজিটরিগুলো আপগ্রেড ব্যর্থ হওয়ার মূল কারণ

Fedora-এর নিজস্ব প্যাকেজগুলো রিলিজের দিনেই একসাথে আপডেট হয়। কিন্তু Fedora-এর বাইরের যেকোনো কিছু অন্য কারো সময়সূচী অনুযায়ী চলে। বেশিরভাগ ভেন্ডর রিপোজিটরি তাদের URL-এ $releasever ব্যবহার করে, তাই আপনি আপগ্রেড করার সাথে সাথেই dnf এমন একটি পাথ খোঁজা শুরু করে যা হয়তো তখনো তৈরি হয়নি।

আপনার সিস্টেমে কী কী আছে তা তালিকাভুক্ত করুন:

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

Fedora-এর নিজস্ব নয় এমন প্রতিটি রিপোজিটরির জন্য, কোনো কিছু চূড়ান্ত করার আগে টার্গেট রিলিজের সাথে সেটিকে পরীক্ষা করে দেখুন:

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

যদি ভেন্ডর সেই রিলিজের জন্য প্যাকেজ প্রকাশ করে থাকে, তবে dnf মেটাডেটা ডাউনলোড করবে এবং নীরবে কাজ শেষ করবে। যদি না করে, তবে আপনি https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml-এর মতো একটি পাথের জন্য 404 এরর পাবেন এবং একই ব্যর্থতার কারণে পরবর্তীতে system-upgrade download আটকে যাবে। Fedora রিলিজের পরবর্তী প্রথম কয়েক সপ্তাহে, আপগ্রেড শুরু না হওয়ার এটিই সবচেয়ে সাধারণ কারণ।

আপনার কাছে দুটি সমাধান আছে। ভেন্ডর প্রকাশ না করা পর্যন্ত কয়েক সপ্তাহ অপেক্ষা করুন, যা সাধারণত সঠিক সিদ্ধান্ত। অথবা সেই রিপোজিটরি ছাড়াই আপগ্রেড করুন:

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

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

ফেডোরা সার্ভারের আপডেট উইন্ডো মিস করলে কী হয়

নির্দিষ্ট দিনে কিছুই ঘটে না। প্যাকেজ ম্যানেজার ব্যবহার করার সময় সমস্যাটি সামনে আসে। এন্ড-অফ-লাইফ রিলিজগুলোকে মিরর নেটওয়ার্ক থেকে আর্কাইভ-এ সরিয়ে নেওয়া হয়, তাই আপনার রিলিজের মেটালিন্ক ইউআরএল-এ 404 এরর আসার কারণে dnf upgrade মেটাডেটা আনতে ব্যর্থ হয়:

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

মেশিনটি ট্রাফিক সার্ভ করা চালিয়ে যায়, যা একে নীরবে বিপজ্জনক করে তোলে। এটি কোনো সিকিউরিটি আপডেট পায় না। এছাড়া কোনো কিছু ইনস্টল করাও সম্ভব হয় না, তাই যেদিন OpenSSH বা nginx-এর কোনো অ্যাডভাইজরি আসে, সেদিন এটি প্যাচ করার কোনো সমর্থিত উপায় আপনার হাতে থাকে না।

এ অবস্থা থেকে বেরিয়ে আসা সম্ভব তবে তা সময়সাপেক্ষ। আপনি রিপোজিটরিগুলোকে https://dl.fedoraproject.org/pub/archive/fedora/linux/-এ ফেডোরা আর্কাইভে পয়েন্ট করতে পারেন এবং সেখান থেকে আপগ্রেড করতে পারেন। ফেডোরা সাধারণত এক বা দুটি রিলিজ পরপর আপগ্রেড করার প্রত্যাশা করে, তাই যদি কোনো সার্ভার চারটি রিলিজ পিছিয়ে থাকে, তবে আপনাকে ধারাবাহিকভাবে কয়েকটি আপগ্রেড করতে হবে। প্রতিটি ধাপেই ব্যর্থতার ঝুঁকি থাকে এবং প্রতিটি ধাপেই অফলাইন বুটে অন্ধের মতো কাজ করতে হয়। একটি ভিপিএস-এর ক্ষেত্রে, বর্তমান ইমেজে নতুন করে বিল্ড করা এবং ডেটা স্থানান্তর করা সাধারণত দ্রুত ও নিরাপদ। এটি নতুন ভিপিএস-এর প্রথম দশ মিনিট-এ বর্ণিত কাজের মতোই।

স্বয়ংক্রিয় আপডেট একটি রিলিজকে প্যাচ করে। এটি কখনোই সেটিকে আপগ্রেড করে না।

Fedora একটি টাইমারের মাধ্যমে তার আপডেটগুলো ইনস্টল করতে পারে:

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

সেটিংসগুলো /etc/dnf/automatic.conf-এ থাকে, যা /usr/share/dnf5/dnf5-plugins/automatic.conf-এ থাকা ডিফল্ট সেটিংসকে ওভাররাইড করে। apply_updates ডিফল্টভাবে বন্ধ থাকে, তাই সরাসরি ব্যবহারের ক্ষেত্রে টাইমারটি আপডেট ডাউনলোড করলেও কিছুই ইনস্টল করে না। upgrade_type-এর মাধ্যমে default এবং security-এর মধ্যে বেছে নেওয়া যায়। reboot-এ never, when-changed অথবা when-needed মান গ্রহণ করা হয়।

এটি আপনাকে একটি রিলিজের ভেতরেই আপ-টু-ডেট রাখে। এটি কখনোই Fedora 43 থেকে Fedora 44-এ নিয়ে যাবে না, কারণ একটি ভার্সন আপগ্রেড হলো একটি আলাদা ও সুপরিকল্পিত প্রক্রিয়া যা অফলাইন ট্রানজ্যাকশনের মাধ্যমে রিবুট করে সম্পন্ন হয়। LTS-এর সাথে এটিই হলো ব্যবহারিক পার্থক্য। Ubuntu-তে, unattended security upgrades কোনো ভার্সন পরিবর্তন ছাড়াই পুরো পাঁচ বছরের উইন্ডো জুড়ে মেশিনকে সচল রাখে এবং ভার্সন পরিবর্তনটি নিজেই কয়েক বছর পর পর 24.04 থেকে 26.04 আপগ্রেড-এর মতো একটি পরিকল্পিত কাজ হিসেবে সম্পন্ন হয়।

কখন Fedora সার্ভার হিসেবে সঠিক পছন্দ

যখন নতুনত্বই মূল লক্ষ্য, তখন Fedora একটি ভালো পছন্দ।

• আপনার এমন কোনো kernel বা userspace প্রয়োজন যা যেকোনো LTS-এর চেয়ে নতুন: যেমন সাম্প্রতিক হার্ডওয়্যার, অথবা এমন কোনো container বা systemd stack যা এন্টারপ্রাইজ রিলিজে আসতে এখনো এক বছর বাকি। Fedora প্রতিটি রিলিজের সময় নতুন upstream kernel-এ আপডেট হয়, তাই এটি কেবল ইনস্টল করার সময়কার সুবিধা নয়।
• আপনি যাচাই করছেন যে কী RHEL (Red Hat Enterprise Linux)-এর দিকে যাচ্ছে। Fedora CentOS Stream-কে সমৃদ্ধ করে, যা আবার RHEL-কে সমৃদ্ধ করে, তাই আজ Fedora-তে যে সফটওয়্যার তৈরি ও রান করছে, তা কয়েক বছর পরের এন্টারপ্রাইজ প্ল্যাটফর্মের জন্য পরীক্ষিত হচ্ছে।
• মেশিনটি পরিকল্পিতভাবেই স্বল্পস্থায়ী। একটি build runner বা test box যা দুই মাস পর ধ্বংস করে ফেলা হবে, তার কখনো end of life তারিখ আসার সুযোগ নেই। একই যুক্তি কোডিং এজেন্টদের দেওয়া disposable VM-এর ক্ষেত্রেও প্রযোজ্য, যেখানে Fedora রিলিজের চেয়ে অনেক বেশি ঘনঘন বক্সটি নতুন করে তৈরি করা হয়।
• আপগ্রেড করার দায়িত্ব নেওয়ার মতো কেউ আছে। একজন নির্দিষ্ট মালিক এবং ক্যালেন্ডারে এন্ট্রি আছে এমন সার্ভারে Fedora বেশ ভালো কাজ করে। যে সার্ভারটি সবাই ভুলে গেছে, সেটির জন্য এটি উপযুক্ত নয়।

মধ্যপন্থা: একটি স্থিতিশীল ভিত্তির ওপর বর্তমান প্যাকেজসমূহ

যারা সার্ভারে Fedora ব্যবহার করতে চান, তাদের বেশিরভাগই মূলত দুই বা তিনটি আধুনিক প্যাকেজ চান, পুরো অপারেটিং সিস্টেমটি আধুনিক হওয়া তাদের মূল লক্ষ্য নয়। এই দুটি বিষয়কে আলাদা করা সম্ভব। একটি LTS বা এন্টারপ্রাইজ রিবিল্ড ডিস্ট্রিবিউশনকে ভিত্তি হিসেবে ব্যবহার করুন, তারপর যেখানে প্রয়োজন সেখানে নতুন সফটওয়্যার যুক্ত করুন। একটি container image আপনাকে এমন একটি হোস্টে নতুন ভার্সনের অ্যাপ্লিকেশন ব্যবহারের সুবিধা দেয়, যার জন্য আপনাকে পুরো সিস্টেম আপগ্রেড করতে হবে না (VPS-এ Docker চালানো)। আপনার প্রয়োজনীয় নির্দিষ্ট প্যাকেজটির জন্য, যেমন PostgreSQL বা nginx-এর ক্ষেত্রে, ভেন্ডর রিপোজিটরি ব্যবহার করলে শুধুমাত্র সেই একটি সফটওয়্যার আপডেট হবে এবং মূল ভিত্তিটি অপরিবর্তিত থাকবে।

উভয় ক্ষেত্রেই সুবিধা ও অসুবিধার ভারসাম্য রয়েছে। একটি কন্টেইনার আপনাকে হোস্টের পুরনো কার্নেলের ওপর একটি নতুন ইউজারস্পেস দেয়, তাই কার্নেল আপডেট প্রয়োজন হলে এটি কোনো কাজে আসে না। একটি ভেন্ডর রিপোজিটরি আপনাকে একটি নতুন প্যাকেজ দেয়, কিন্তু সেই প্যাকেজটি মূল সিস্টেমের সাথে ভেন্ডরের দ্বারা কম পরীক্ষিত হতে পারে। উভয় পদ্ধতিতেই মূল সিস্টেমের নিরাপত্তা আপডেট LTS-এর সময়সূচী অনুযায়ী চলে, আর Fedora-তে এই সময়সূচীটিই প্রতি বছর রক্ষণাবেক্ষণের জন্য একটি নির্দিষ্ট সময়ের দাবি রাখে।

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

FAQ

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

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

আমি কি একটি Fedora রিলিজ বাদ দিয়ে সরাসরি দুটি ভার্সন আপগ্রেড করতে পারি?

হ্যাঁ, নির্দিষ্ট সীমার মধ্যে। dnf system-upgrade download --releasever= একটি বা দুটি রিলিজ পরের টার্গেট গ্রহণ করতে পারে, এবং বছরে একবার আপগ্রেড করার ক্ষেত্রে দুটি ভার্সন একসাথে লাফিয়ে যাওয়াই নিয়ম। এর চেয়ে বেশি ভার্সন টপকে যাওয়া সমর্থিত নয়, কারণ প্রতিটি অতিরিক্ত রিলিজের ক্ষেত্রে প্যাকেজের নাম পরিবর্তন বা কনফিগারেশন ফরম্যাট পরিবর্তনের কারণে ট্রানজ্যাকশন ব্যর্থ হওয়ার সম্ভাবনা বেড়ে যায়। যদি কোনো মেশিন ইতিমধ্যে বেশ কয়েকটি রিলিজ পিছিয়ে থাকে এবং end of life পার করে ফেলে, তবে একের পর এক আপগ্রেড করার চেয়ে বর্তমান ইমেজ দিয়ে নতুন করে সেটআপ করা সাধারণত দ্রুততর হয়।

আমার Fedora সার্ভার end of life-এ পৌঁছালে কী হবে?

এটি চলতে থাকবে কিন্তু কোনো প্যাচ পাবে না। পরবর্তী dnf upgrade কমান্ডটি আপনার রিলিজের মেটালিন্ক URL-এ 404 error দেখাবে, কারণ end of life হয়ে যাওয়া রিলিজগুলোকে dl.fedoraproject.org-এ আর্কাইভে সরিয়ে নেওয়া হয়। আপনি রিপোজিটরি ফাইলগুলোকে সেই আর্কাইভে পয়েন্ট করে ধাপে ধাপে আপগ্রেড করতে পারেন, অথবা একটি সমর্থিত রিলিজ ব্যবহার করে সার্ভারটি নতুন করে তৈরি করতে পারেন। এই দুটির যেকোনো একটি না করা পর্যন্ত, মেশিনে কোনো security update পৌঁছাবে না এবং কোনো প্যাকেজ ইনস্টল হবে না।

প্রোডাকশন সার্ভারের জন্য কি Fedora একটি খারাপ পছন্দ?

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