Ubuntu 24.04 سے 26.04 پر VPS upgrade کب کریں؟

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

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

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

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

یہ آپ کے server میں کوئی fault نہیں ہے۔ /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 سے گزارے گا۔ یہ interim releases ہیں اور سب end of life ہو چکی ہیں۔ اسے lts پر رہنے دیں اور انتظار کریں۔ Canonical کے schedule میں تاریخیں تبدیل ہو سکتی ہیں، اس لیے اگر مقررہ دن خاموشی سے گزر جائے تو دوبارہ check کریں۔

ذیل کی ہر command آپ کو خود اپنے server پر، دی گئی ترتیب سے چلانی ہے۔ جس machine کو upgrade کیا جا رہا ہو، اسی پر release upgrade کی rehearsal نہیں کی جا سکتی۔ یہ kernel اور C library کو replace کرتا ہے، اور مکمل ہونے کے لیے 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 کام نہیں کرتا، lockout کے بعد بہت دیر ہو جاتی ہے۔
• آپ ایک گھنٹے کا downtime برداشت نہیں کر سکتے اور آپ کے پاس rollback کا طریقہ نہیں ہے۔
• آپ کا stack کسی ایسے third-party repository پر منحصر ہے جس نے ابھی تک resolute کے لیے package publish نہیں کیا۔
• server کو دو سال سے زیادہ عرصہ پہلے ہاتھ سے build کیا گیا تھا اور کسی کو معلوم نہیں کہ اس پر کیا موجود ہے۔

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

مرحلہ 1: ایسا بیک اپ لیں جس سے بحالی کی جا سکے

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

پہلے databases کو دستی طور پر dump کریں۔ database کو روکے بغیر قابلِ اعتماد backup صرف dump ہی ہوتا ہے۔

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 وہ file ہے جس کی طرف آپ عملی طور پر رجوع کریں گے، کیونکہ اس میں ہر config file موجود ہوتی ہے جس کے بارے میں upgrade آپ سے ابھی سوال کرنے والا ہے۔

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

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

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

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 کے ساتھ fail ہو جاتا ہے۔ عموماً وجہ پرانے kernels ہوتے ہیں، اور sudo apt --purge autoremove انہیں صاف کر دیتا ہے۔

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

مرحلہ 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، اور deb822 .sources files جن میں Types: اور Suites: fields ہوتے ہیں۔ Upgrade کے دوران دونوں formats غیر فعال کر دیے جاتے ہیں۔ ubuntu-security-status --thirdparty ان installed packages کی فہرست دیتا ہے جنہیں Ubuntu کا کوئی archive فراہم نہیں کرتا۔ یہ ان packages کی اصل تعداد ہے جو آپ نے اضافی طور پر install کیے ہیں۔ /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 structure فراہم کرتے ہیں۔ کسی ایسے 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 کو غیر فعال رہنے دیں۔ Codename کو ایسے codename سے تبدیل کرنا جس کے لیے vendor نے package بنایا ہو، غلط system libraries سے linked packages install کرنے کا سبب بنتا ہے۔

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

اگر plain login shell میں do-release-upgrade چلتے وقت آپ کا کنکشن منقطع ہو جائے تو process کو SIGHUP ملتا ہے اور unpacking کے دوران یہ رک جاتا ہے۔ اس سے dpkg جزوی طور پر configure رہ جاتا ہے، اور ممکن ہے کہ server میں دوبارہ کنکشن قائم کرنے کے لیے working network stack بھی نہ رہے۔ اس کے بجائے اسے terminal multiplexer کے اندر چلائیں، تاکہ client کے منقطع ہونے کے بعد بھی 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 میں rule شامل نہیں کرتا، کیونکہ اجازت لیے بغیر firewall میں راستہ کھولنا غیر متوقع اور نامناسب ہوگا۔ شروع کرنے سے پہلے 1022 خود کھولیں، اور sudo ufw delete allow 1022/tcp مکمل ہونے کے بعد اسے بند کر دیں۔ یاد رکھیں کہ آپ کا provider server سے باہر اپنے control panel میں دوسرا firewall چلا سکتا ہے۔

اگر اس کے باوجود کنکشن منقطع ہو جائے تو دوبارہ login کریں اور tmux attach -t upgrade چلائیں۔ آپ کی غیر موجودگی میں upgrade چلتا رہا۔

مرحلہ 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 کو باہم ہم آہنگ کریں۔

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

ہر file جسے list کیا گیا ہے، maintainer کا version ہے جو آپ کی file کے ساتھ محفوظ کیا گیا ہے۔ انہیں ایک ایک کر کے diff کریں اور اہم settings کو اپنی file میں منتقل کریں۔ دو 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 کریں، پھر مشین چیک کریں

sudo reboot

جب مشین دوبارہ چل جائے:

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 کو صفر units کی فہرست دینی چاہیے؛ اگر یہ کچھ فہرست کرے تو وہ آپ کا اگلا کام ہے۔ آخری apt update ان updates کو حاصل کرتا ہے جو release images بنائے جانے کے بعد شائع ہوئی ہیں۔

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

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

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

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

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

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

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

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

اول، mysqld اس وقت start نہیں ہوتا جب اس کی config میں ایسا option شامل ہو جسے نئے version نے ہٹا دیا ہو۔ default_authentication_plugin عام option ہے، کیونکہ بہت سی پرانی guides اسے set کرنے کی ہدایت کرتی ہیں۔ service fail ہو جاتی ہے، اور journalctl -u mysql -n 50 نامعلوم variable کی براہ راست نشاندہی کرتا ہے۔ /etc/mysql/mysql.conf.d/ کے تحت موجود file سے وہ line delete کریں، پھر 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 کر سکتے ہیں۔ اسے end date والی عارضی تدبیر سمجھیں، کیونکہ یہ plugin مکمل طور پر ختم ہونے کے مرحلے میں ہے۔

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

24.04 کے ساتھ PHP 8.3 اور 26.04 کے ساتھ PHP 8.5 جاری کیا جاتا ہے۔ Packages versioned paths میں install ہوتے ہیں، اور کوئی چیز آپ کے web server config کو خودکار طور پر rewrite نہیں کرتی۔ ایسا nginx vhost جس میں fastcgi_pass unix:/run/php/php8.3-fpm.sock; موجود ہو، اب ایسے 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 کریں، config 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

mod_php کے ساتھ Apache میں علامت مختلف ہوتی ہے۔ 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 مکمل طور پر missing ہوگی۔

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

SSH: وہ خرابی جو موجودہ سیشن ختم کر دیتی ہے

sshd_config prompt وہ جگہ ہے جہاں لوگ خود کو سرور سے باہر کر دیتے ہیں۔ Y کا جواب دینے سے maintainer کی file انسٹال ہو جاتی ہے، جو آپ کی PermitRootLogin، PasswordAuthentication، AllowUsers، Port اور آپ کی شامل کردہ ہر دوسری line حذف کر دیتی ہے۔ اگر آپ کا firewall صرف custom port کی اجازت دیتا ہے اور packaged config، port 22 پر listening کرتی ہے تو اگلا connection مسترد ہو جائے گا، اور آپ کا موجودہ 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 میں آپ کی کوئی setting باقی نہ رہے تو وہ prompt اہم نہیں رہتا۔ دونوں میں سے کوئی بھی جواب دینے سے آپ کی settings برقرار رہتی ہیں، کیونکہ وہ ایک مختلف file میں موجود ہوتی ہیں۔

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

systemctl is-enabled ssh.socket

اگر اس سے 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 پر بھی listening کرتی ہے۔ اسے sudo systemctl daemon-reload && sudo systemctl restart ssh.socket کے ساتھ لاگو کریں۔

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 کو سخت محفوظ بنانا اس drop-in file میں برقرار رکھنے کے قابل settings کی وضاحت کرتا ہے۔

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

FAQ

Ubuntu 24.04 پر do-release-upgrade، "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 کی مقررہ تاریخ 27 August 2026 ہے۔ اس دن تک 24.04 server کو کوئی نئی release نظر نہیں آئے گی۔ setting کو تبدیل نہ کریں اور Prompt=normal پر switch نہ کریں، کیونکہ اس سے آپ interim releases کے راستے پر چلے جائیں گے۔

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

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

کیا مجھے 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 کے دوران یہ ایک گھنٹے کے لیے یک طرفہ راستہ بن جاتا ہے۔

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

عام login shell میں process کو SIGHUP ملتا ہے اور وہ دورانِ عمل بند ہو جاتا ہے، جس سے dpkg کی configuration نامکمل رہ جاتی ہے۔ اسے 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 configuration اب بھی اسی 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 کرنا ہے۔