Fedora سرور کی 13 ماہ کی support مدت اور upgrade

Fedora کی ایک release کو security updates کب تک ملتی ہیں؟

Fedora server کے لیے تقریباً ہر سال version upgrade ضروری ہوتا ہے، اور یہ عمل machine کے موجود رہنے تک جاری رہتا ہے۔ Fedora تقریباً ہر 6 ماہ بعد نئی release جاری کرتا ہے۔ ہر release کو اس کے بعد آنے والی دوسری version کے release کے تقریباً 4 ہفتے بعد تک support ملتی ہے۔ اس طرح updates کی مدت تقریباً 13 ماہ بنتی ہے۔ اس تاریخ کے بعد release کو کوئی security fix نہیں ملتی۔ server چلتا رہتا ہے، لیکن اس میں موجود packages کے لیے مزید patches جاری نہیں کیے جاتے۔

تاریخوں سے صورتِ حال واضح ہو جاتی ہے۔ August 2026 تک supported releases 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 کے جاری ہونے کے 4 ہفتے بعد۔ اس لیے Fedora 42 image سے بنایا گیا server، کسی کی غلطی کے بغیر، 13 ماہ بعد support سے باہر ہو گیا۔

Fedora بمقابل LTS، ماہ میں

LTS سے مراد long term support ہے: ایسی release جسے vendor مہینوں کے بجائے برسوں تک patches فراہم کرتا رہتا ہے۔ EOL سے مراد end of life ہے، یعنی وہ تاریخ جب patches فراہم ہونا بند ہو جاتے ہیں۔ ذیل میں ہر project کی جانب سے اس release کے لیے شائع کردہ مدت دی گئی ہے جسے آپ آج install کریں گے۔

[
  {
    "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 جیسا enterprise rebuild 120 ماہ فراہم کرتا ہے۔ دوسرے کالم کو درکار upgrade کی تعداد سمجھیں۔ دس سال کے دوران Fedora پورے operating system کے تقریباً 10 upgrades کا تقاضا کرتا ہے، جبکہ Ubuntu LTS پر یہ تعداد 2 ہے۔ Debian کے لیے 36 ماہ کی مدت اس کی معمول کی security support ہے، اور الگ LTS team زیادہ تر releases کی support کو تقریباً 5 سال تک بڑھا دیتی ہے۔

یہ شائع کردہ support windows ہیں، جن کی اگست 2026 میں جانچ کی گئی ہے؛ یہ measured uptime نہیں ہیں۔ مختلف cadences کی وجوہات Ubuntu LTS اور server پر interim releases کے درمیان فرق میں بیان کی گئی ہیں۔ یہاں اہم بات یہ ہے کہ ہر option آپ کے لیے کتنا انتظامی کام پیدا کرتا ہے۔

Fedora version upgrade میں اصل میں کیا ہوتا ہے

Fedora 41 سے DNF 5 ڈیفالٹ package manager ہے، اور dnf اسے چلاتا ہے۔ system-upgrade command خود dnf5 کا حصہ ہے، اس لیے پہلے کوئی plugin install کرنے کی ضرورت نہیں۔ اگر آپ Debian یا Ubuntu سرور سے آ رہے ہیں تو روزمرہ استعمال ہونے والی زیادہ تر commands کے لیے apt سے dnf کا براہِ راست متبادل موجود ہے، لیکن ذیل میں بیان کردہ version upgrade ان چند کاموں میں شامل ہے جس کا کوئی حقیقی متبادل موجود نہیں۔ موجودہ release سے شروع کریں اور اسے مکمل طور پر patch کریں:

sudo dnf upgrade --refresh
sudo reboot

Reboot اس لیے اہم ہے کہ upgrade کا حل installed اور running نظام کی حالت کے مطابق نکلتا ہے۔ اس لیے اگر kernel یا glibc update جزوی طور پر apply ہوئی ہو تو اگلے مرحلے کی وجہ سمجھنا مشکل ہو جاتا ہے۔ اب نئی release کو stage کریں۔ 44 کو اس release کے نمبر سے بدلیں جس پر آپ منتقل ہو رہے ہیں:

sudo dnf system-upgrade download --releasever=44

یہ پوری transaction کا حل نکالتا ہے اور ہر package download کرتا ہے، لیکن running system میں کوئی تبدیلی نہیں کرتا۔ ایک چھوٹے server پر چند ہزار packages اور 1 سے 3 gigabytes کی توقع رکھیں۔ اگر dnf transaction کا حل نہ نکال سکے تو یہیں رک جاتا ہے اور اس package کا نام بتاتا ہے جس نے اسے روکا۔ یہ بہتر صورت ہے، کیونکہ failure اس وقت ہوتا ہے جب machine ابھی چل رہی ہوتی ہے اور آپ کے پاس shell موجود ہوتا ہے۔

اب اسے چلائیں:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status تصدیق کرتا ہے کہ transaction stage ہو چکی ہے اور انتظار کر رہی ہے۔ dnf system-upgrade reboot machine کو offline transaction کے لیے restart کرتا ہے۔ اس میں minimal boot ہوتا ہے اور RPM transaction خود چلتی ہے۔ ایسا اس لیے کیا جاتا ہے کہ running services کے نیچے glibc اور systemd کو تبدیل کرنے سے system جزوی طور پر install شدہ حالت میں رہ سکتا ہے۔ پوری transaction کے دوران آپ کا server unreachable رہے گا۔ ایک چھوٹے VPS پر اس میں عموماً کئی منٹ لگتے ہیں، پھر server نئی release میں دوبارہ reboot ہوتا ہے۔ دو reboots اور اس مدت کے لیے منصوبہ بنائیں جب 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) جیسی line دکھانی چاہیے۔ log subcommand اس offline boot کی transaction log دکھاتا ہے۔ جب آپ کے پاس shell نہیں تھا، اس دوران کیا ہوا، اس کا یہی واحد record ہوتا ہے۔ distro-sync نئی release کے versions کے مطابق پیچھے رہ جانے والی چیزوں کو update کرتا ہے۔ repoquery --extras ان installed packages کی فہرست دکھاتا ہے جو اب کسی enabled repository میں موجود نہیں ہیں۔ یہی وہ جگہ ہے جہاں ایسی repository کے leftovers ملتے ہیں جس نے نئی release کے لیے packages شائع نہیں کیے۔

Download کے مرحلے سے پہلے disk کا snapshot لیں۔ Transaction ایسے وقت چلتی ہے جب آپ screen نہیں دیکھ سکتے۔ اگر offline boot کے دوران یہ fail ہو جائے تو SSH واپس نہیں آئے گا، اور داخل ہونے کا واحد طریقہ provider کا دیا ہوا console، VNC یا serial ہوگا۔ شروع کرنے سے پہلے تصدیق کریں کہ آپ کے پاس console یا snapshot موجود ہے، بعد میں نہیں۔

ایک اور check جسے لوگ چھوڑ دیتے ہیں:

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

جب کوئی package نئی default config file فراہم کرتا ہے اور آپ نے پرانی file میں ترمیم کی ہو تو RPM آپ کی file کو overwrite نہیں کرتا۔ یہ packaged version کو .rpmnew کے نام سے اس کے ساتھ لکھ دیتا ہے۔ اس لیے آپ کا sshd یا nginx پرانی release کی طرح ہی چلتا رہتا ہے، جبکہ نئی defaults disk پر پڑی رہتی ہیں اور استعمال نہیں ہوتیں۔ ہر upgrade کے بعد ان files کو پڑھیں۔ rpmconf install کرنے اور sudo rpmconf -a چلانے سے یہ files ایک ایک کر کے کھلتی ہیں اور ان کا فرق دکھائی دیتا ہے۔

فریق ثالث کی repositories ہی upgrade کو ناکام بناتی ہیں

Fedora کے اپنے packages release کے دن ایک ساتھ update ہوتے ہیں۔ Fedora سے باہر کی ہر چیز کسی اور schedule کے مطابق update ہوتی ہے۔ زیادہ تر vendor repositories اپنے URL میں $releasever شامل کرتی ہیں، اس لیے upgrade کرتے ہی dnf ایسے path کے لیے درخواست بھیجنا شروع کر دیتا ہے جو ابھی موجود نہ ہو۔

اپنی موجودہ repositories کی فہرست دیکھیں:

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

Fedora کی اپنی repository کے علاوہ ہر repository کو upgrade شروع کرنے سے پہلے target release کے ساتھ test کریں:

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

اگر vendor نے اس release کے لیے package شائع کیا ہے تو dnf metadata download کر کے خاموشی سے exit ہو جاتا ہے۔ اگر ایسا نہ ہو تو https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml جیسے path کے لیے 404 ملتا ہے، اور یہی failure بعد میں system-upgrade download کو روک دے گا۔ Fedora release کے بعد ابتدائی ہفتوں میں upgrade شروع نہ ہونے کی سب سے عام وجہ یہی ہوتی ہے۔

آپ کے پاس دو راستے ہیں۔ Vendor کے package شائع کرنے کے لیے چند ہفتے انتظار کریں، جو عموماً درست فیصلہ ہوتا ہے۔ یا اس repository کے بغیر upgrade کریں:

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

کسی repository کو disable کرنے سے اس کے packages remove نہیں ہوتے۔ وہ installed اور unmanaged رہتے ہیں، اور اگر وہ transaction کو روکیں تو dnf اس کی اطلاع دیتا ہے۔ --allowerasing شامل کرنے سے dnf conflict حل کرنے کے لیے installed packages remove کر سکتا ہے، اس لیے قبول کرنے سے پہلے removal list پڑھیں۔ اسی list میں وہ database server بھی شامل ہو سکتا ہے جسے آپ برقرار رکھنا چاہتے تھے۔

وقت گزرنے کے بعد Fedora server کے ساتھ کیا ہوتا ہے

اسی دن کچھ نہیں ہوتا۔ خرابی اگلی بار package manager استعمال کرنے پر ظاہر ہوتی ہے۔ End of life releases کو 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 updates نہیں ملتیں۔ یہ کوئی بھی چیز install نہیں کر سکتی۔ چنانچہ جس دن OpenSSH یا nginx کا security advisory جاری ہو، اسے patch کرنے کا کوئی supported طریقہ آپ کے پاس نہیں رہتا۔

اس صورتِ حال سے نکلنا ممکن ہے، لیکن اس میں وقت لگتا ہے۔ آپ repositories کو Fedora کے archive پر https://dl.fedoraproject.org/pub/archive/fedora/linux/ کے مقام پر redirect کر کے وہاں سے upgrade کر سکتے ہیں۔ Fedora عموماً ایک وقت میں ایک یا دو releases آگے بڑھنے کی توقع رکھتا ہے۔ اس لیے جو box چار releases پیچھے ہو، اسے مسلسل کئی hops سے گزرنا پڑتا ہے۔ ہر hop میں failure کا الگ امکان ہوتا ہے، اور ہر مرحلے میں offline boot کے دوران آپ کے پاس محدود visibility رہتی ہے۔ VPS پر current image سے نیا server بنانا اور data منتقل کرنا عموماً زیادہ مختصر اور محفوظ طریقہ ہوتا ہے۔ یہ وہی کام ہے جو نئے VPS کے ابتدائی دس منٹ میں کیا جاتا ہے۔

خودکار updates کسی release پر patches لاگو کرتے ہیں۔ وہ اسے کبھی upgrade نہیں کرتے۔

Fedora مقررہ timer کے ذریعے اپنے updates install کر سکتا ہے:

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

Settings، /etc/dnf/automatic.conf میں موجود ہوتی ہیں، جو shipped defaults کو /usr/share/dnf5/dnf5-plugins/automatic.conf میں override کرتی ہے۔ apply_updates بطور default بند ہوتا ہے، اس لیے ابتدائی configuration میں timer updates download کرتا ہے لیکن کچھ install نہیں کرتا۔ upgrade_type، default اور security میں سے انتخاب کرتا ہے۔ reboot، never، when-changed یا when-needed قبول کرتا ہے۔

اس سے آپ ایک ہی release کے اندر تازہ ترین حالت میں رہتے ہیں۔ یہ Fedora 43 کو کبھی Fedora 44 میں منتقل نہیں کرے گا، کیونکہ version upgrade ایک الگ اور دانستہ operation ہے جس میں offline transaction کے لیے reboot کیا جاتا ہے۔ یہی LTS کے مقابلے میں عملی فرق ہے۔ Ubuntu پر غیر نگرانی شدہ security upgrades version تبدیل کیے بغیر پورے پانچ سالہ عرصے میں machine کو updated رکھتے ہیں، جبکہ version change خود ایک منصوبہ بند کام ہوتا ہے، جیسے ہر چند سال بعد 24.04 سے 26.04 کا upgrade۔

سرور چلانے کے لیے Fedora کب موزوں ہے

Fedora اس وقت اچھا انتخاب ہے جب جدید ہونا بنیادی ضرورت ہو۔

• آپ کو کسی بھی LTS میں دستیاب kernel یا userspace سے زیادہ نیا ورژن درکار ہو: مثلاً جدید hardware، یا ایسا container اور systemd stack جو enterprise release میں شامل ہونے سے ابھی ایک سال دور ہو۔ Fedora کسی release کے دوران بھی نئے upstream kernels پر منتقل ہوتا رہتا ہے، اس لیے یہ فائدہ صرف installation کے وقت تک محدود نہیں ہوتا۔
• آپ یہ جانچ رہے ہوں کہ RHEL (Red Hat Enterprise Linux) میں کیا شامل ہونے والا ہے۔ Fedora، CentOS Stream کو software فراہم کرتا ہے، اور CentOS Stream، RHEL کو؛ اس لیے جو software آج Fedora پر build اور run ہو رہا ہے، اسے چند سال بعد کے enterprise platform کے مطابق test کیا جا رہا ہوتا ہے۔
• مشین کو جان بوجھ کر مختصر مدت کے لیے استعمال کیا جانا ہو۔ ایسا build runner یا test box جو دو ماہ بعد destroy کر دیا جائے، اپنی end of life تاریخ تک نہیں پہنچتا۔ یہی اصول coding agents کو دی جانے والی disposable VMs پر بھی لاگو ہوتا ہے، جہاں box کو Fedora releases کے مقابلے میں کہیں زیادہ کثرت سے rebuild کیا جاتا ہے۔
• upgrade کی ذمہ داری کسی مخصوص شخص کے پاس ہو۔ Fedora ایسے server پر موزوں ہے جس کا named owner ہو اور calendar entry مقرر ہو۔ یہ اس box کے لیے ناقص انتخاب ہے جسے سب بھول چکے ہوں۔

معتدل راستہ: مستحکم بنیاد پر موجودہ packages

زیادہ تر لوگ جو server پر Fedora چاہتے ہیں، انہیں موجودہ operating system کے بجائے صرف دو یا تین موجودہ packages درکار ہوتے ہیں۔ یہ دونوں چیزیں الگ رکھی جا سکتی ہیں۔ بنیاد کے طور پر LTS یا enterprise rebuild چلائیں، پھر جہاں واقعی ضرورت ہو وہاں نیا software شامل کریں۔ container image آپ کو ایسے host پر application کا نیا version فراہم کرتی ہے جسے اس مقصد کے لیے کبھی upgrade کرنے کی ضرورت نہیں پڑتی (VPS پر Docker چلانا)۔ جس واحد package کی آپ کو ضرورت ہو، مثلاً PostgreSQL یا nginx، اس کے لیے vendor repository استعمال کرنے سے صرف وہ package جدید ہوتا ہے اور base جوں کی توں رہتی ہے۔

اس انتخاب کے دونوں پہلو واضح ہیں۔ container، host کے پرانے kernel پر نیا userspace فراہم کرتا ہے، اس لیے اگر آپ کو kernel ہی اپ ڈیٹ کرنا ہو تو یہ مدد نہیں کرتا۔ vendor repository ایسی base پر ایک نیا package فراہم کرتی ہے جسے vendor نے کم حد تک test کیا ہوتا ہے۔ دونوں صورتوں میں base system کی security updates LTS کے schedule کے مطابق رہتی ہیں، اور Fedora کے ساتھ ہر سال maintenance window درکار ہونے کی اصل وجہ بھی یہی schedule ہے۔

اگر آپ server کے لیے Fedora منتخب کرتے ہیں تو اس cycle کو calendar میں درج کریں۔ جب کوئی release جاری ہو، تو vendor repositories کے ہم آہنگ ہونے کے لیے چند ہفتے انتظار کریں، snapshot بنائیں، upgrade کریں، پھر تصدیق کریں کہ services دوبارہ شروع ہو گئی ہیں۔ اس طریقۂ کار پر سالانہ تقریباً ایک گھنٹہ لگتا ہے اور یہ مؤثر ہے۔ ناکام ہونے والا طریقۂ کار وہ ہے جس میں upgrade صرف اس وقت یاد آتا ہے جب کوئی چیز پہلے ہی خراب ہو چکی ہو۔

FAQ

Fedora کی ایک ریلیز کتنے عرصے تک معاونت یافتہ رہتی ہے؟

تقریباً 13 ماہ۔ Fedora تقریباً ہر چھ ماہ بعد ایک ریلیز جاری کرتا ہے اور ہر ریلیز کو اس کے دو ورژن بعد والی ریلیز جاری ہونے کے تقریباً چار ہفتے بعد تک معاونت فراہم کرتا ہے۔ Fedora 44، 28 April 2026 کو جاری ہوئی، اور اس کی end of life جون 2027 میں مقرر ہے۔ یہ تاریخ گزرنے کے بعد ریلیز کو security updates ملنا بند ہو جاتے ہیں، اور اس کے packages mirrors سے ہٹا کر Fedora کے archive میں منتقل کر دیے جاتے ہیں۔

کیا میں Fedora کی ایک ریلیز چھوڑ کر بیک وقت دو ورژن upgrade کر سکتا ہوں؟

ہاں، لیکن کچھ حدود کے اندر۔ dnf system-upgrade download --releasever= ایک یا دو ریلیز آگے کے target کو قبول کرتا ہے، اور ایک وقت میں دو ریلیز آگے جانا عین اسی طرح ہے جیسے سال میں ایک بار upgrade کرنے کا معمول ہو۔ اس سے زیادہ آگے جانا supported path نہیں ہے، اور ہر اضافی ریلیز کے ساتھ package rename یا config format کی تبدیلی سے transaction رکنے کا امکان بڑھ جاتا ہے۔ اگر کوئی machine پہلے ہی کئی ریلیز پیچھے ہو اور end of life سے گزر چکی ہو تو upgrades کی زنجیر چلانے کے بجائے current image پر اسے دوبارہ بنانا عموماً زیادہ تیز ہوتا ہے۔

اگر میرے Fedora server کی end of life ہو جائے تو کیا ہوتا ہے؟

Server چلتا رہتا ہے، لیکن اس پر patches آنا بند ہو جاتے ہیں۔ اگلا dnf upgrade آپ کی ریلیز کے metalink URL پر 404 error کے ساتھ ناکام ہو جاتا ہے، کیونکہ end of life ریلیزز کو dl.fedoraproject.org پر archive میں منتقل کر دیا جاتا ہے۔ آپ repository files میں اس archive کا پتہ درج کر کے مرحلہ وار upgrade کر سکتے ہیں، یا supported release پر server دوبارہ بنا سکتے ہیں۔ ان دونوں میں سے کوئی ایک کام کرنے تک machine کو کوئی security update نہیں مل سکتا اور کوئی package install نہیں ہو گا۔

کیا production server کے لیے Fedora ایک خراب انتخاب ہے؟

یہ default انتخاب کے طور پر نامناسب ہے، لیکن مناسب وجہ موجود ہو تو قابلِ عمل انتخاب ہے۔ اس کی لاگت یہ ہے کہ ہر سال مکمل operating system upgrade کرنا پڑتا ہے، اور یہ عمل اس machine پر مستقل جاری رہتا ہے جسے آپ شاید تبدیل نہیں کرنا چاہتے۔ Fedora اس وقت منتخب کریں جب آپ کو LTS کے جاری کردہ kernel یا userspace سے نیا kernel یا userspace درکار ہو، یا جب server کو منصوبہ بندی کے مطابق مختصر مدت کے لیے چلانا ہو۔ جب آپ کسی server کا version تبدیل کیے بغیر کئی سال تک اس پر patches لگانا چاہتے ہوں تو LTS یا enterprise rebuild منتخب کریں۔