Ubuntu 24.04 سے 26.04 upgrade کب اور کیسے کریں؟

آپ Ubuntu 24.04 کو 26.04 میں کب upgrade کر سکتے ہیں؟

آپ VPS پر Ubuntu 24.04 کو 26.04 میں اس وقت upgrade کر سکتے ہیں جب 26.04.1 point release جاری ہو جائے۔ یہ 27 August 2026 کو متوقع ہے۔ اس وقت تک 24.04 server کو نئی release نظر نہیں آئے گی، اور یہ جان بوجھ کر ایسا ہوگا۔ Ubuntu 26.04 LTS (Resolute Raccoon) 23 April 2026 کو جاری ہوا، لیکن Canonical پہلے point release تک LTS سے LTS upgrade path فعال نہیں کرتا۔ اس کی وجہ یہ ہے کہ اس release میں پہلے چند ماہ کے دوران سامنے آنے والے installation اور upgrade bugs شامل کر کے درست کیے جاتے ہیں۔ اگر یہ numbering آپ کے لیے نئی ہے تو 26.04.1 کوئی مختلف Ubuntu نہیں بلکہ وہی 26.04 ہے جس کے installation media میں چار ماہ کی fixes شامل کی گئی ہیں۔ اسی لیے Canonical موجودہ server کے لیے یہی پہلی version پیش کرے گا۔

August 2026 کے شروع میں 24.04 box پر check چلائیں تو یہ نتیجہ ملے گا:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

یہ آپ کے server کی خرابی نہیں ہے۔ /etc/update-manager/release-upgrades میں Ubuntu Server پر Prompt=lts شامل ہے۔ اس کا مطلب ہے کہ یہ tool صرف اگلی long term support release پیش کرتا ہے، اور وہ بھی اس وقت جب اس کی .1 point release موجود ہو۔ Prompt=normal set کرنے سے 24.10، 25.04 اور 25.10 باری باری install کرنے کا عمل شروع ہوگا۔ یہ interim releases اب end of life ہو چکی ہیں۔ اسے lts پر رہنے دیں اور انتظار کریں۔ Canonical کے schedule میں تاریخیں تبدیل ہو سکتی ہیں، اس لیے اگر مقررہ دن خاموشی سے گزر جائے تو دوبارہ check کریں۔

نیچے دی گئی ہر command آپ خود اپنے server پر، اسی ترتیب سے چلائیں گے۔ جس machine کو upgrade کیا جا رہا ہو، اسی پر release upgrade کی rehearsal نہیں کی جا سکتی۔ اس عمل میں kernel اور C library تبدیل ہوتے ہیں، اور تکمیل کے لیے reboot ضروری ہوتا ہے۔

کیا آپ کو upgrade کرنا بھی چاہیے؟

Ubuntu 24.04 کو 2029 تک standard security updates ملتی رہیں گی، اس لیے کام کرنے والے production server کے لیے فوری upgrade کی ضرورت نہیں ہے۔ اس وقت upgrade کریں جب آپ کو وہ چیز درکار ہو جو 26.04 میں شامل ہے: PHP 8.5، PostgreSQL 18، MySQL 8.4 LTS، OpenSSH 10.2 یا 7.0 kernel۔ صرف یہ وجہ کہ "number بڑھ گیا ہے"، ایسے machine کو چھیڑنے کے لیے کافی نہیں جو customers کو service دے رہی ہو۔

مندرجہ ذیل میں سے کوئی بات درست ہو تو in-place upgrade نہ کریں:

• آپ نے اپنے provider کا console (VNC یا serial) کبھی نہیں کھولا اور اس کے ذریعے login نہیں کیا۔ اگر SSH ناکام ہو جائے تو یہی console server تک دوبارہ رسائی کا واحد طریقہ ہے۔ یہ معلوم ہونا کہ console کام نہیں کرتا، اس وقت بہت دیر ہو گی جب آپ خود lock out ہو چکے ہوں۔
• آپ ایک گھنٹے کا downtime برداشت نہیں کر سکتے اور آپ کے پاس rollback کا طریقہ نہیں ہے۔
• آپ کا stack کسی ایسے third-party repository پر منحصر ہے جس نے ابھی تک resolute کے لیے packages شائع نہیں کیے۔
• server دو سال سے زیادہ پہلے ہاتھ سے بنایا گیا تھا اور کسی کو معلوم نہیں کہ اس پر کیا موجود ہے۔

اکثر بہتر متبادل یہ ہوتا ہے کہ ایک نیا 26.04 VPS بنائیں، اپنا stack install کریں، data restore کریں، اور درست response ملنے کے بعد DNS تبدیل کر دیں۔ آپ پرانا server اس وقت تک چلاتے رہتے ہیں جب تک نیا server خود کو ثابت نہ کر دے، اور rollback restore کے بجائے DNS change بن جاتا ہے۔ اگر آپ یہ طریقہ اختیار کریں تو نئے VPS کے پہلے دس منٹ سے آغاز کریں اور نیا server درست طریقے سے تیار کریں۔

مرحلہ 1: ایسا backup لیں جس سے restore کیا جا سکے

دو layers استعمال کریں، کیونکہ یہ مختلف طریقوں سے fail ہوتی ہیں۔ Provider snapshot پوری disk کو محفوظ کرتا ہے اور چند منٹ میں restore ہو جاتا ہے، لیکن یہ اس وقت لیا جاتا ہے جب آپ کے databases میں writing جاری ہوتی ہے۔ اس لیے یہ application-consistent کے بجائے crash-consistent ہوتا ہے۔ restic سے file-level backup لیں اور اسے server سے باہر محفوظ رکھیں۔ اس سے آپ کو انفرادی files ملتی ہیں اور ایسی copy بھی رہتی ہے جو آپ کا account lock ہونے کے بعد بھی دستیاب رہتی ہے۔

پہلے databases کو دستی طور پر dump کریں۔ Database کا وہی backup قابل اعتماد ہوتا ہے جسے بناتے وقت database کو روکنے کی ضرورت نہ ہو۔

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction صرف InnoDB tables کے لیے consistent dump بناتا ہے۔ MyISAM tables کے لیے database کو روکنا ضروری ہے۔ /etc tarball وہ backup ہے جسے آپ عملی طور پر استعمال کریں گے، کیونکہ اس میں ہر وہ config file شامل ہوتی ہے جس کے بارے میں upgrade آپ سے سوال کرنے والا ہے۔

جس backup سے آپ نے کبھی restore نہیں کیا، وہ صرف ایک اندازہ ہے۔ ابھی اس backup سے ایک file نکال کر دیکھیں، اس سے پہلے کہ دباؤ کی حالت میں واقعی اس کی ضرورت پڑے۔

مرحلہ 2: پہلے 24.04 کو مکمل طور پر patch کریں

do-release-upgrade ایسے system پر چلنے سے انکار کرتا ہے جس میں packages کی state خراب ہو، اور آدھا patch کیا ہوا 24.04 بعد کی ہر failure کو سمجھنا مشکل بنا دیتا ہے۔

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit کا کچھ بھی print نہ کرنا اس بات کی علامت ہے کہ کوئی package half configured نہیں ہے۔ apt-mark showhold کا کچھ بھی print نہ کرنا اس بات کی علامت ہے کہ کوئی package ایسی version پر pinned نہیں ہے جو upgrade کو روک سکے۔ sudo apt-mark unhold اور package name کے ذریعے اس کی فہرست میں موجود ہر hold ختم کریں، یا تسلیم کریں کہ hold کسی وجہ سے موجود ہے اور یہیں رک جائیں۔

اگر kernel تبدیل ہوا ہے تو reboot کریں، تاکہ upgrade ایسی machine سے ہو جو وہی code چلا رہی ہو جسے وہ اپنے مطابق چلا رہی ہے۔

[ -f /var/run/reboot-required ] && sudo reboot

اس کے بعد disk space چیک کریں۔ upgrader کسی بھی چیز کو install کرنے سے پہلے پورا نیا package set download کرتا ہے، اور کافی جگہ نہ ہونے پر filesystem کا نام بتا کر رک جاتا ہے۔

df -h / /boot

/ پر تقریباً 5 GB سے کم free space ہونے کی صورت میں مسئلہ پیدا ہوتا ہے۔ 300 MB سے کم والا /boot بعد میں kernel install کے دوران No space left on device کے ساتھ failure کا شکار ہوتا ہے۔ عموماً وجہ پرانے kernels ہوتے ہیں، اور sudo apt --purge autoremove انہیں صاف کر دیتا ہے۔

شروع کرنے سے پہلے ایک اور چیز روکیں: اگر خودکار security updates دورانِ عمل شروع ہو جائیں تو وہ dpkg lock برقرار رکھتی ہیں، اور release upgrader Could not get lock /var/lib/dpkg/lock-frontend کے ساتھ رک جاتا ہے۔ پہلے sudo systemctl stop unattended-upgrades چلائیں، پھر اس کے مکمل ہونے پر upgrade دوبارہ شروع کریں۔

مرحلہ 3: third-party repositories اور pinned packages کی جانچ کریں

do-release-upgrade ہر اس apt source کو غیر فعال کرتا ہے جو Ubuntu کا نہ ہو، کیونکہ noble کے لیے بنایا گیا package resolute system کو خراب کر سکتا ہے۔ یہ بعد میں ان sources کو دوبارہ فعال کر دیتا ہے جنہیں یہ شناخت لیتا ہے، جبکہ باقی کو commented out چھوڑ دیتا ہے۔ Tool کو فیصلہ کرنے دینے سے پہلے معلوم کریں کہ آپ کے system میں کیا شامل ہے۔

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 اس directory میں دو formats استعمال کرتا ہے: پرانی one-line .list files، اور Types: اور Suites: fields والی deb822 .sources files۔ Upgrade کے دوران دونوں disabled ہو جاتی ہیں۔ ubuntu-security-status --thirdparty ان installed packages کی فہرست دیتا ہے جن کا کوئی Ubuntu archive provider نہیں ہے۔ یہ ان packages کی درست تعداد ہے جو آپ نے اضافی طور پر نصب کیے ہیں۔ /etc/apt/preferences.d/ میں موجود ہر چیز ایک pin ہے، اور noble کے لیے لکھی گئی pin نئے release پر بھی پرانا package منتخب کرتی رہے گی۔

ہر third-party repository کے لیے upgrade شروع کرنے سے پہلے تصدیق کریں کہ vendor نے نئے codename کے لیے package جاری کیا ہے۔ Docker کی suites https://download.docker.com/linux/ubuntu/dists/ پر درج ہیں، اور دیگر vendors بھی یہی directory فراہم کرتے ہیں۔ ایسے suite کی طرف اشارہ کرنے والا source جو موجود ہی نہیں، upgrade کے بعد پہلے apt update پر یہ output دیتا ہے:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Vendor کے package جاری کرنے تک اس source کو disabled رہنے دیں۔ Codename کو ایسے codename سے تبدیل کرنا جس کے لیے vendor نے package بنایا ہو، غلط system libraries کے خلاف linked packages نصب کرنے کا سبب بنتا ہے۔

مرحلہ 4: اپ گریڈ کو سادہ SSH shell کے بجائے tmux میں چلائیں

اگر سادہ login shell میں do-release-upgrade چلتے وقت آپ کا connection منقطع ہو جائے تو process کو SIGHUP ملتا ہے اور unpacking کے دوران process رک جاتا ہے۔ اس سے dpkg کی configuration نامکمل رہ جاتی ہے، اور ممکن ہے کہ server کے پاس دوبارہ connect کرنے کے لیے working network stack بھی نہ رہے۔ اس کے بجائے اسے terminal multiplexer کے اندر چلائیں، تاکہ client disconnect ہونے کے بعد بھی process server پر چلتا رہے۔

sudo apt install -y tmux
tmux new -s upgrade

اس session کے اندر:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

Upgrader کسی بھی تبدیلی سے پہلے port 1022 پر دوسرا SSH daemon شروع کرتا ہے اور اس کی اطلاع دیتا ہے:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

یہ اس port کے لیے firewall خود نہیں کھولتا، کیونکہ اجازت کے بغیر firewall میں راستہ بنانا غیر متوقع اور نامناسب ہوگا۔ شروع کرنے سے پہلے 1022 خود کھولیں، اور sudo ufw delete allow 1022/tcp مکمل ہونے پر اسے بند کر دیں۔ یاد رکھیں کہ آپ کا provider اپنے control panel میں server سے باہر ایک دوسرا firewall بھی چلا سکتا ہے۔

اگر اس کے باوجود connection منقطع ہو جائے تو دوبارہ login کریں اور tmux attach -t upgrade چلائیں۔ آپ کی غیر موجودگی میں upgrade جاری رہا ہوگا۔ اگر ایسا نہ ہوا ہو، اور واپس آنے پر dpkg یا apt sources کی configuration ادھوری ہو، جس میں کچھ حصہ noble اور کچھ حصہ resolute ہو، تو failed release upgrade کی بحالی package state کی مرمت کرنے اور یہ فیصلہ کرنے کا طریقہ بتاتا ہے کہ مرمت کب روک کر snapshot restore کرنا چاہیے۔

مرحلہ 5: configuration file کے prompts کا سوچ سمجھ کر جواب دیں

dpkg صرف ان files کے بارے میں prompt دکھاتا ہے جنہیں آپ یا کسی script نے تبدیل کیا ہو۔ اس لیے ہر prompt ایسی file سے متعلق ہوتا ہے جسے آپ نے جان بوجھ کر edit کیا ہے۔ اسے ختم کرنے کے لیے صرف enter دبانے سے hardened server خاموشی سے default configuration پر واپس آ سکتا ہے۔

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

ہر بار پہلے D دبائیں۔ دیکھیں کہ کیا تبدیل ہوا ہے، پھر N کے ذریعے اپنا version برقرار رکھیں۔ default پہلے ہی N ہوتا ہے، اور یہی محفوظ جواب ہے، کیونکہ آپ کی file آج کام کر رہی ہے جبکہ packaged file اس machine پر کبھی چلی ہی نہیں۔

اپنی file برقرار رکھنے کی ایک قیمت ہے: آپ کو نئے defaults نہیں ملیں گے۔ بعد میں، system کے up ہونے کے بعد اور وقت کے دباؤ سے باہر، دونوں versions کو reconcile کریں۔

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

ہر file جس کے بارے میں یہ option ظاہر ہوتا ہے، maintainer کا version ہوتا ہے اور اسے آپ کی file کے ساتھ محفوظ کیا جاتا ہے۔ ان کا ایک وقت میں ایک diff دیکھیں اور اہم settings کو اپنی file میں copy کریں۔ دو files پر خاص توجہ دیں: /etc/ssh/sshd_config، کیونکہ غلط جواب آپ کا session ختم کر دے گا؛ اور web server config، کیونکہ غلط جواب websites کو down کر دے گا۔

upgrade یہ بھی پوچھتا ہے کہ کن services کو restart کرنا ہے، اور یہ کام needrestart کے ذریعے ہوتا ہے۔ مکمل list قبول کریں۔ اگر کوئی daemon ایسی shared library file استعمال کرتے ہوئے چلتا رہے جسے disk سے delete کر دیا گیا ہو، تو بعد میں کسی request پر crash ہو سکتا ہے، ایسے وقت میں جب آپ اس کی نگرانی نہیں کر رہے ہوں۔

مرحلہ 6: reboot کریں، پھر machine چیک کریں

sudo reboot

جب machine دوبارہ آن ہو جائے:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a کو Release: 26.04 اور Codename: resolute رپورٹ کرنا چاہیے۔ uname -r میں 7.0 kernel دکھائی دینا چاہیے۔ systemctl --failed کو zero units دکھانے چاہییں، اور اگر یہ کوئی unit دکھائے تو وہ آپ کا اگلا کام ہے۔ آخری apt update، release images بنائے جانے کے بعد شائع ہونے والی updates حاصل کرتا ہے۔

PostgreSQL 16 سے 18: وہ cluster جو خاموشی سے پرانا رہ جاتا ہے

Ubuntu 24.04 میں PostgreSQL 16 اور Ubuntu 26.04 میں PostgreSQL 18 جاری ہوتا ہے۔ upgrade کے دوران 18، 16 کے ساتھ الگ install ہوتا ہے اور آپ کا data منتقل نہیں ہوتا۔ Debian کی postgresql-common layer نئی major version کے لیے اگلے دستیاب port پر نیا خالی cluster بناتی ہے۔ چنانچہ 16، آپ کے تمام data کے ساتھ port 5432 پر چلتا رہتا ہے، جبکہ 18، port 5433 پر خالی موجود ہوتا ہے۔ آپ کی application بدستور 5432 سے رابطہ کرتی رہتی ہے اور بظاہر کوئی مسئلہ نظر نہیں آتا۔ اسی لیے لوگ یہ مسئلہ کئی ماہ بعد دریافت کرتے ہیں۔

pg_lsclusters

دو clusters کی فہرست ظاہر ہونے کا مطلب ہے کہ migration نہیں ہوئی۔ یہ کام اس وقت کریں جب application روک سکیں:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

پہلے خالی 18 cluster کو drop کریں، کیونکہ pg_upgradecluster ایسے target cluster میں data نہیں لکھے گا جو پہلے سے موجود ہو۔ default طریقہ 16 کا dump لے کر اسے 18 میں reload کرتا ہے، اس لیے database کے حجم کے تقریباً برابر خالی disk space درکار ہوگی۔ -m upgrade اس کے بجائے pg_upgrade استعمال کرتا ہے اور بڑے database پر کہیں زیادہ تیز ہے۔ عمل مکمل ہونے کے بعد Port column پڑھیں: نیا cluster 5432 سنبھال لیتا ہے اور پرانا cluster stopped حالت میں رہتا ہے۔ analyze pass خود چلائیں، کیونکہ نئے load کیے گئے cluster میں statistics موجود نہیں ہوتیں اور ابتدائی queries سست ہوں گی۔

چند دن تک application کو نئے cluster کے خلاف test کریں۔ اس کے بعد ہی پرانے cluster کو remove کریں:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

پرانے cluster کی data directory آپ کے پاس موجود تیز ترین rollback ذریعہ ہے۔ upgrade کے دن اسے delete نہ کریں۔

MySQL 8.0 سے 8.4: حذف کیا گیا option جو server کو روک دیتا ہے

26.04، MySQL کو 8.0 سے 8.4 LTS پر منتقل کرتا ہے، اور دو تبدیلیاں servers کو متاثر کرتی ہیں۔

اول، mysqld اس وقت start ہونے سے انکار کرتا ہے جب اس کی configuration میں ایسا option موجود ہو جسے نئے version نے حذف کر دیا ہو۔ default_authentication_plugin عام option ہے، کیونکہ بہت سی پرانی guides اسے set کرنے کی ہدایت دیتی ہیں۔ service fail ہو جاتی ہے، اور journalctl -u mysql -n 50 نامعلوم variable کو براہ راست ظاہر کرتا ہے۔ /etc/mysql/mysql.conf.d/ کے تحت موجود file سے یہ line حذف کریں، پھر sudo systemctl start mysql۔

دوم، mysql_native_password plugin اب 8.4 میں default طور پر enabled نہیں ہے، اس لیے جو account اب بھی اسے استعمال کرتا ہے وہ بالکل login نہیں کر سکتا۔ 8.0 پر رہتے ہوئے یہ check کریں:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

mysql_native_password ظاہر کرنے والے ہر account کو upgrade سے پہلے منتقل کریں، پھر اپنی application config میں password update کریں:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

اگر کوئی client library اتنی پرانی ہے کہ caching_sha2_password کے ساتھ بات نہیں کر سکتی، تو [mysqld] کے تحت mysql_native_password=ON شامل کر کے 8.4 میں پرانا plugin دوبارہ enabled کر سکتے ہیں۔ اسے آخری تاریخ والی عارضی تدبیر سمجھیں، کیونکہ یہ plugin مکمل طور پر ختم ہونے کی راہ پر ہے۔

PHP 8.3 سے 8.5: آپ کے vhosts اب ایسے socket کی طرف اشارہ کرتے ہیں جو موجود نہیں

24.04 میں PHP 8.3 اور 26.04 میں PHP 8.5 شامل ہے۔ Packages versioned paths میں install ہوتے ہیں، اور آپ کی web server configuration خودکار طور پر rewrite نہیں ہوتی۔ fastcgi_pass unix:/run/php/php8.3-fpm.sock; رکھنے والا nginx vhost اب ایسے socket کی طرف اشارہ کرتا ہے جسے کوئی process create نہیں کرتا۔ اس لیے ہر PHP request 502 واپس کرتی ہے، اور nginx error log میں یہ درج ہوتا ہے:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

اسے نئے socket کی طرف point کریں، configuration test کریں، پھر reload کریں:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Apache میں mod_php استعمال کرنے پر علامت مختلف ہوتی ہے۔ Apache بالکل start نہیں ہوگا، اور sudo apache2ctl -t بتاتا ہے کہ وہ libphp8.3.so load نہیں کر سکتا کیونکہ file موجود نہیں۔ Enabled module ایسے package کا symlink ہے جو اب موجود نہیں رہا۔

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

اگر آپ نے box Ubuntu 24.04 پر LAMP stack سے تیار کیا تھا تو ان دونوں paths کو ضرور check کریں۔ اس صورت میں guide آپ کو versioned module name اور versioned socket کے ساتھ چھوڑتی ہے۔

آپ کی php.ini tuning بھی منتقل نہیں ہوتی۔ memory_limit، upload_max_filesize اور آپ کی مقرر کردہ دیگر settings /etc/php/8.3/ میں موجود ہوتی ہیں، جبکہ نئی tree defaults سے شروع ہوتی ہے۔ دونوں files کا diff دیکھیں اور values دستی طور پر منتقل کریں۔ پوری پرانی file کو نئی file پر copy کرنے سے 8.3 defaults، 8.5 installation میں آ جاتے ہیں۔ پھر php -m چلائیں اور موازنہ کریں۔ php8.3-redis کے طور پر installed extension کو اس کے php8.5- package کی ضرورت ہوتی ہے۔ اگر یہ PPA سے آئی تھی تو upgrader نے وہ source disable کر دیا ہوگا، اور extension مکمل طور پر غائب ہوگی۔

Certificates کے لیے الگ سے ایک check کریں۔ Upgrade کے بعد sudo certbot renew --dry-run چلائیں۔ یہ live certificate کو تبدیل کیے بغیر renewal path کا مکمل test کرتا ہے، جس میں web server reload hook بھی شامل ہے۔ اگر کوئی hook ایسے service name یا binary کو call کرتا ہے جو تبدیل ہو چکا ہے تو یہ مسئلہ 60 دن بعد خاموشی سے پیدا ہونے کے بجائے اسی وقت آپ کے سامنے ظاہر ہو جاتا ہے۔ nginx پر Let's Encrypt کے ساتھ Certbot میں بتایا گیا ہے کہ ان hooks کی شکل کیسی ہونی چاہیے۔

SSH: وہ خرابی جو آپ کے موجودہ session کو ختم کر دیتی ہے

sshd_config prompt وہ مقام ہے جہاں لوگ خود کو server سے باہر کر لیتے ہیں۔ Y کا جواب دینے سے maintainer کی file install ہو جاتی ہے، جو آپ کے PermitRootLogin، PasswordAuthentication، AllowUsers، Port اور آپ کی شامل کردہ ہر دوسری line کو حذف کر دیتی ہے۔ اگر آپ کا firewall صرف custom port کی اجازت دیتا ہے اور packaged config، 22 پر listen کرتی ہے تو اگلا connection reject ہو جائے گا، اور موجودہ session آپ کا آخری session ہو گا۔

upgrade سے پہلے اسے روکیں۔ 24.04 پر /etc/ssh/sshd_config کا آغاز Include /etc/ssh/sshd_config.d/*.conf سے ہوتا ہے، اور OpenSSH ہر setting کے لیے پہلی پڑھی جانے والی value برقرار رکھتا ہے۔ اس لیے اوپر شامل کی گئی drop-in file، اس کے نیچے موجود ہر چیز پر غالب آتی ہے۔ اپنی settings ایسی file میں منتقل کریں جس کی ملکیت dpkg کے پاس نہ ہو:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

جب /etc/ssh/sshd_config میں آپ کی کوئی چیز باقی نہ رہے تو وہ prompt اہم نہیں رہتا۔ دونوں صورتوں میں آپ کی settings برقرار رہیں گی، کیونکہ وہ مختلف file میں موجود ہیں۔

Custom port کے لیے ایک اور جانچ ضروری ہے، کیونکہ ممکن ہے وہ وہاں نہ ہو جہاں آپ سمجھ رہے ہیں:

systemctl is-enabled ssh.socket

اگر اس کا output enabled ہو تو listening port کا انتظام systemd کے پاس ہے، اور sshd_config میں موجود Port line نظرانداز کی جاتی ہے۔ Ubuntu نے 22.10 سے sshd کے لیے socket activation استعمال کیا ہے۔ اسی وجہ سے Port 2222 میں کی گئی تبدیلی بے اثر دکھائی دیتی ہے۔ اسے socket unit پر sudo systemctl edit ssh.socket کے ذریعے set کریں:

[Socket]
ListenStream=
ListenStream=2222

خالی ListenStream= ضروری ہے۔ یہ inherited value کو صاف کرتا ہے۔ اس کے بغیر socket، 22 کے ساتھ 2222 پر بھی listen کرے گا۔ اسے sudo systemctl daemon-reload && sudo systemctl restart ssh.socket کے ذریعے apply کریں۔

upgrade کے بعد، موجودہ session بند کرنے سے پہلے:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

پھر اپنی machine پر دوسرا terminal کھولیں اور دوبارہ login کریں۔ دوسرے terminal میں کام کرنے والا shell ہی قابل اعتماد ثبوت ہے۔ جب تک یہ ثابت نہ ہو جائے، پہلا session کھلا رکھیں۔ VPS پر SSH کو harden کرنا اس drop-in میں رکھنے کے قابل settings کی وضاحت کرتا ہے۔

اگر اب بہت دیر ہو چکی ہے تو آپ کے provider کا web console ایسا login فراہم کرتا ہے جو SSH استعمال نہیں کرتا۔ وہاں login کریں، config درست کریں، sudo sshd -t چلائیں، اور service restart کریں۔ یہی console اس بات کی وجہ ہے کہ upgrade سے پہلے console access کی جانچ کی جائے، upgrade کے دوران نہیں۔

FAQ

do-release-upgrade Ubuntu 24.04 پر "No new release found" کیوں دکھاتا ہے؟

کیونکہ Ubuntu Server پر /etc/update-manager/release-upgrades میں Prompt=lts شامل ہے، اور یہ setting اگلی long term support release صرف اس وقت پیش کرتی ہے جب اس کی پہلی point release دستیاب ہو۔ Ubuntu 26.04 LTS، 23 April 2026 کو جاری ہوئی، جبکہ 26.04.1 کی scheduled تاریخ 27 August 2026 ہے۔ اس دن تک 24.04 server کو کوئی نئی release نظر نہیں آئے گی۔ اس setting کو تبدیل نہ کریں، کیونکہ Prompt=normal پر تبدیل کرنے سے آپ interim releases کے راستے پر چلے جائیں گے۔

کیا upgrade مکمل کرنے کے لیے server کو reboot کرنا ضروری ہے؟

ہاں۔ Upgrade کے دوران نیا kernel، نئی C library اور نیا init system install ہوتا ہے۔ چلتا ہوا system restart ہونے تک پرانے components استعمال کرتا رہتا ہے۔ do-release-upgrade آخر میں reboot کرنے کا کہتا ہے، اور جو machine "بعد میں" تک چلتی رہتی ہے، اس میں دو releases کے components کا ملا جلا نظام چل رہا ہوتا ہے۔ Server واپس آنے کے بعد نئے kernel کے لیے uname -r دیکھیں، اور ان services کے لیے systemctl --failed چیک کریں جو دوبارہ شروع نہیں ہوئیں۔

کیا مجھے in-place upgrade کرنا چاہیے یا نیا 26.04 server بنانا چاہیے؟

جب ممکن ہو، نیا server بنائیں۔ نیا VPS آپ کو stack install کرنے، data restore کرنے اور ہر چیز test کرنے دیتا ہے، جبکہ پرانا server network traffic فراہم کرتا رہتا ہے۔ اس طرح rollback، backup سے restore کرنے کے بجائے DNS change بن جاتا ہے۔ In-place upgrade اس وقت کریں جب server پر ایسا stateful data ہو جسے منتقل کرنا مشکل ہو، provider ہر machine کے حساب سے billing کرتا ہو، یا آپ کے پاس snapshot اور آزمودہ console access موجود ہو۔ In-place طریقہ معروف اور بارہا استعمال شدہ ہے، لیکن جس ایک گھنٹے میں یہ چلتا ہے، اس دوران واپسی کا راستہ نہیں رہتا۔

اگر upgrade کے دوران میرا SSH connection ختم ہو جائے تو کیا ہوگا؟

عام login shell میں process کو SIGHUP موصول ہوتا ہے اور وہ درمیان میں بند ہو جاتا ہے، جس سے dpkg جزوی طور پر configure رہ جاتا ہے۔ Process کو tmux یا screen کے اندر شروع کریں۔ اس طرح process جاری رہتا ہے، اور reconnect کرنے کے بعد اسے مکمل کرنے کے لیے tmux attach -t upgrade چلایا جا سکتا ہے۔ Upgrader port 1022 پر ایک اضافی SSH daemon بھی شروع کرتا ہے تاکہ داخل ہونے کا دوسرا راستہ موجود رہے، لیکن یہ اس port کے لیے firewall rule نہیں بناتا۔ اس لیے پہلے 1022 کی اجازت خود دیں اور بعد میں اسے بند کر دیں۔

Upgrade کے بعد میری PHP site 502 واپس کرتی ہے۔ کیا خراب ہوا؟

Version تبدیل ہونے کے ساتھ PHP FPM socket path بھی تبدیل ہو گیا۔ Ubuntu 24.04 میں PHP 8.3 اور 26.04 میں PHP 8.5 چلتا ہے، اس لیے /run/php/php8.3-fpm.sock اب موجود نہیں، جبکہ آپ کا nginx vhost اب بھی اسی path کا نام دے رہا ہے۔ nginx error log میں connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) دکھائی دے گا۔ fastcgi_pass کو 8.5 socket پر update کریں، sudo nginx -t چلائیں، پھر nginx reload کریں۔ Apache میں mod_php استعمال ہونے کی صورت میں متعلقہ اصلاح sudo a2dismod php8.3 کے بعد sudo a2enmod php8.5 چلانا اور service restart کرنا ہے۔