Fedora Server کو کتنے عرصے بعد upgrade کرنا ہوگا؟

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

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

تاریخیں صورتِ حال کو واضح کرتی ہیں۔ 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 کے آنے کے چار ہفتے بعد۔ اس لیے Fedora 42 image سے بنائے گئے server کی support تیرہ ماہ بعد ختم ہو گئی، حالانکہ کسی نے کوئی غلطی نہیں کی تھی۔

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

LTS کا مطلب long term support ہے: ایسی release جس کے لیے vendor مہینوں کے بجائے برسوں تک patches جاری رکھتا ہے۔ EOL کا مطلب end of life ہے، یعنی وہ تاریخ جب patches جاری ہونا بند ہو جاتے ہیں۔ ذیل میں وہ مدتیں دی گئی ہیں جو ہر project آج install کی جانے والی 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 جیسی enterprise rebuild 120 دیتی ہے۔ دوسرے کالم کو مطلوبہ upgrade work سمجھیں۔ دس سال کے دوران Fedora میں پورے operating system کو تقریباً 10 بار upgrade کرنا پڑتا ہے، جبکہ Ubuntu LTS میں یہ تعداد 2 ہے۔ Debian کے لیے 36 ماہ کی مدت اس کی معمول کی security support ہے، اور ایک الگ LTS team زیادہ تر releases کی support مدت تقریباً پانچ سال تک بڑھا دیتی ہے۔

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

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

Fedora 41 سے DNF 5 default package manager ہے، اور dnf اسے چلاتا ہے۔ system-upgrade command خود dnf5 کا حصہ ہے، اس لیے پہلے کوئی plugin install کرنے کی ضرورت نہیں۔ موجودہ release سے آغاز کریں اور system کو مکمل طور پر patch کریں:

sudo dnf upgrade --refresh
sudo reboot

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

sudo dnf system-upgrade download --releasever=44

یہ پوری transaction resolve کرتا ہے اور ہر package download کرتا ہے، لیکن running system میں کوئی تبدیلی نہیں کرتا۔ ایک چھوٹے server پر چند ہزار packages اور 1 سے 3 gigabytes download ہونے کی توقع رکھیں۔ اگر dnf transaction resolve نہ کر سکے تو یہیں رک جاتا ہے اور اس 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 کو replace کرنے سے system آدھا install ہو سکتا ہے۔ پوری transaction کے دوران آپ کا server unreachable رہے گا۔ ایک چھوٹے VPS پر عموماً کئی منٹ لگتے ہیں، پھر machine نئی release میں دوبارہ reboot ہوتی ہے۔ 2 reboots اور اس window کے لیے منصوبہ بنائیں جس میں 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 نہیں تھا، اس دوران کیا ہوا، اس کا یہی واحد record ہوتا ہے۔ distro-sync نئی release کے versions پر پیچھے رہ جانے والی تمام چیزیں لے آتا ہے۔ repoquery --extras ایسے installed packages دکھاتا ہے جو اب کسی enabled repository میں موجود نہیں ہیں۔ یہیں سے اس repo کے leftovers ملتے ہیں جس نے نئی release کے لیے packages publish نہیں کیے۔

Download step سے پہلے 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 day پر ایک ساتھ update ہوتے ہیں۔ Fedora سے باہر کے packages کسی اور کے 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/

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

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

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

آپ کے پاس دو راستے ہیں۔ چند ہفتے انتظار کریں تاکہ vendor repository شائع کر دے۔ عموماً یہی درست طریقہ ہے۔ یا اس 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 پڑھیں۔ اسی فہرست میں وہ database server بھی شامل ہو سکتا ہے جسے آپ برقرار رکھنا چاہتے تھے۔

ایسا Fedora server جس نے مقررہ مدت گنوا دی ہو، اس کے ساتھ کیا ہوتا ہے

اسی دن کچھ نہیں ہوتا۔ خرابی اگلی بار ظاہر ہوتی ہے جب آپ package manager استعمال کرتے ہیں۔ End of life releases کو mirror network سے archive میں منتقل کر دیا جاتا ہے، اس لیے dnf upgrade metadata حاصل کرتے وقت fail ہو جاتا ہے۔ آپ کی 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 آگے بڑھیں گے۔ اس لیے چار releases پیچھے موجود machine کو مسلسل کئی hops درکار ہوں گے۔ ہر hop کے fail ہونے کا اپنا امکان ہوتا ہے، اور ہر مرحلہ offline boot میں محدود visibility کے ساتھ چلتا ہے۔ VPS پر current image سے دوبارہ build کر کے data منتقل کرنا عموماً زیادہ مختصر اور محفوظ کام ہوتا ہے۔ یہ وہی کام ہے جو نئے VPS کے پہلے دس منٹ میں کیا جاتا ہے۔

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

Fedora timer کے ذریعے اپنی updates انسٹال کر سکتا ہے:

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 میں فراہم کردہ default ترتیبات کو override کرتی ہیں۔ apply_updates بطور default بند ہوتا ہے، اس لیے ابتدائی configuration میں timer updates download کرتا ہے لیکن کچھ انسٹال نہیں کرتا۔ upgrade_type، default اور security کے درمیان انتخاب کرتا ہے۔ reboot، never، when-changed یا when-needed قبول کرتا ہے۔

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

Fedora کب درست server انتخاب ہے

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

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

معتدل راستہ: مستحکم بنیاد پر موجودہ 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 پر رہتے ہیں، اور یہی schedule وہ حصہ ہے جو Fedora پر ہر سال maintenance window کا تقاضا کرتا ہے۔

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

FAQ

Fedora کی ایک release کتنے عرصے تک supported رہتی ہے؟

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

کیا میں Fedora کی ایک release چھوڑ کر ایک ہی بار میں دو versions upgrade کر سکتا ہوں؟

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

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

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

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

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