Ubuntu 24.04 থেকে 26.04-এ upgrade করার সঠিক সময়

কখন Ubuntu 24.04 থেকে 26.04-এ upgrade করা যাবে?

26.04.1 point release প্রকাশিত হলে VPS-এ Ubuntu 24.04 থেকে 26.04-এ upgrade করা যাবে। এই 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-সংক্রান্ত bug-গুলোর সমাধান একত্র করা হয়।

August 2026-এর শুরুতে 24.04 box-এ check চালালে আপনি এটি পাবেন:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

এটি আপনার server-এর কোনো fault নয়। Ubuntu Server-এ /etc/update-manager/release-upgrades-এর মধ্যে Prompt=lts থাকে। এর অর্থ, tool-টি শুধু পরবর্তী long term support release অফার করে, এবং সেটিও কেবল তার .1 point release প্রকাশিত হলে। Prompt=normal সেট করলে 24.10, 25.04 এবং 25.10 ধারাবাহিকভাবে upgrade করার নির্দেশনা পাবেন। এগুলো interim release এবং সবগুলোর end of life হয়ে গেছে। lts অপরিবর্তিত রেখে অপেক্ষা করুন। Canonical-এর schedule-এর তারিখ পরিবর্তিত হতে পারে। তাই নির্ধারিত তারিখ পার হয়ে গেলেও নতুন release না এলে আবার check করুন।

নিচের প্রতিটি command আপনাকেই নিজের server-এ, দেওয়া ক্রমে চালাতে হবে। যে machine-এ upgrade করছেন, সেই machine-এ release upgrade-এর rehearsal করা যায় না। এই প্রক্রিয়ায় kernel এবং C library প্রতিস্থাপিত হয়। এটি সম্পূর্ণ করতে reboot প্রয়োজন।

আদৌ কি upgrade করা উচিত?

Ubuntu 24.04 2029 সাল পর্যন্ত standard security updates পাবে। তাই সচল production server upgrade করার কোনো সময়সীমার চাপ নেই। 26.04-এ থাকা কোনো সুবিধা দরকার হলে upgrade করুন: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 অথবা 7.0 kernel। শুধু “সংখ্যা বেড়েছে” কোনো customer service চালানো machine-এ পরিবর্তন আনার কারণ নয়।

নিচের যেকোনো একটি সত্য হলে in-place upgrade করবেন না:

• আপনি কখনো provider-এর console (VNC বা serial) খুলে সেখানে login করেননি। SSH কাজ না করলে ওই console-ই server-এ ফেরার একমাত্র উপায়। আর access হারানোর পর console কাজ করে না জানতে পারলে তখন অনেক দেরি হয়ে যাবে।
• আপনি এক ঘণ্টার downtime সামলাতে পারবেন না এবং কোনো rollback ব্যবস্থা নেই।
• আপনার stack এমন কোনো third-party repository-এর ওপর নির্ভরশীল, যা এখনো resolute-এর জন্য package প্রকাশ করেনি।
• server-টি দুই বছরের বেশি সময় ধরে হাতে তৈরি করা হয়েছে এবং এতে কী কী আছে তা কেউ জানে না।

অনেক সময় বিকল্প পদ্ধতিই ভালো: নতুন 26.04 VPS তৈরি করুন, আপনার stack install করুন এবং data restore করুন। নতুন server সঠিকভাবে response দিলে DNS পরিবর্তন করুন। নতুন server নিজেকে প্রমাণ না করা পর্যন্ত পুরোনো server চালু রাখতে পারবেন। ফলে rollback করতে restore নয়, শুধু DNS পরিবর্তন করতে হবে। এই পদ্ধতি নিলে নতুন VPS-এর প্রথম দশ মিনিট দিয়ে শুরু করুন এবং নতুন server সঠিকভাবে তৈরি করুন।

ধাপ 1: যেটি থেকে পুনরুদ্ধার করতে পারবেন, এমন একটি ব্যাকআপ নিন

দুটি স্তর ব্যবহার করুন, কারণ এগুলো ভিন্নভাবে ব্যর্থ হয়। Provider snapshot পুরো disk ধারণ করে এবং কয়েক মিনিটের মধ্যে পুনরুদ্ধার করা যায়। তবে database-গুলোতে write চলার সময় snapshot নেওয়া হয়। তাই এটি application-consistent নয়, crash-consistent। সার্ভারের বাইরে সংরক্ষিত restic দিয়ে file-level backup নিলে একক file পুনরুদ্ধার করা যায়। আপনার account lock হয়ে গেলেও এই backup-এর একটি copy অক্ষত থাকে।

প্রথমে হাতে database dump নিন। Database বন্ধ না করে নির্ভরযোগ্যভাবে নেওয়া যায়, এমন একমাত্র 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 table-এর জন্য consistent dump দেয়। MyISAM table-এর ক্ষেত্রে database বন্ধ করতে হবে। /etc tarball-টিই আপনি বাস্তবে ব্যবহার করবেন, কারণ upgrade চলাকালে যেসব config file নিয়ে প্রশ্ন করা হবে, সেটির মধ্যে সেগুলো সব থাকে।

যে backup কখনও restore করে পরীক্ষা করা হয়নি, সেটি কেবল একটি অনুমান। এখনই সেখান থেকে একটি file বের করে দেখুন, যাতে চাপের সময় এটি প্রয়োজন হলে সমস্যা না হয়।

ধাপ 2: আগে 24.04 সম্পূর্ণভাবে patch করুন

ভাঙা package state থাকা সিস্টেমে do-release-upgrade চলতে অস্বীকার করে। অর্ধেক patch করা 24.04 পরবর্তী প্রতিটি failure-এর কারণ বোঝা কঠিন করে তোলে।

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

dpkg --audit কোনো output না দিলে বুঝবেন, কোনো package half configured অবস্থায় নেই। apt-mark showhold কোনো output না দিলে বুঝবেন, কোনো package এমন version-এ pinned নেই যা upgrade আটকে দেবে। তালিকায় থাকা প্রতিটি package-এর জন্য sudo apt-mark unhold এবং package name চালিয়ে hold ছাড়ুন। অথবা hold থাকার কারণ থাকলে সেটি মেনে নিয়ে এখানেই থামুন।

kernel পরিবর্তিত হলে reboot করুন। এতে সিস্টেম যে code চালাচ্ছে বলে মনে করছে, সেই code চালানো অবস্থার machine থেকেই upgrade হবে।

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

এরপর disk space পরীক্ষা করুন। upgrader কোনো package install করার আগে সম্পূর্ণ নতুন package set download করে। পর্যাপ্ত জায়গা না থাকলে filesystem-এর নাম উল্লেখ করে এটি বন্ধ হয়ে যায়।

df -h / /boot

/-এ প্রায় 5 GB-এর কম free space থাকলে সাধারণত এই সমস্যা হয়। 300 MB-এর কম /boot থাকলে পরে kernel install-এর সময় No space left on device দিয়ে failure হয়। এর সাধারণ কারণ পুরোনো kernel। sudo apt --purge autoremove সেগুলো সরিয়ে দেয়।

শুরু করার আগে আরেকটি বিষয় বন্ধ করুন: স্বয়ংক্রিয় security update চলাকালে dpkg lock ধরে রাখলে release upgrader Could not get lock /var/lib/dpkg/lock-frontend দিয়ে থেমে যায়। আগে sudo systemctl stop unattended-upgrades চালান। কাজ শেষ হলে আবার এটি শুরু করুন।

ধাপ 3: তৃতীয় পক্ষের repository এবং pinned package পরীক্ষা করুন

do-release-upgrade Ubuntu-এর নয় এমন প্রতিটি apt source নিষ্ক্রিয় করে, কারণ noble-এর জন্য তৈরি package resolute system-এ সমস্যা সৃষ্টি করতে পারে। এটি পরে যেগুলো চিনতে পারে সেগুলো পুনরায় সক্রিয় করে এবং বাকিগুলো comment out অবস্থায় রাখে। tool-টি আপনার হয়ে সিদ্ধান্ত নেওয়ার আগে আপনি কী ব্যবহার করছেন তা যাচাই করুন।

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-তে দুটি format ব্যবহার করে: পুরোনো এক-লাইন .list file এবং Types: ও Suites: field-সহ deb822 .sources file। upgrade-এর সময় উভয় format-ই নিষ্ক্রিয় করা হয়। কোনো Ubuntu archive যে installed package সরবরাহ করে না, ubuntu-security-status --thirdparty সেগুলোর তালিকা দেয়। আপনি নিজে যুক্ত করা package-এর প্রকৃত সংখ্যা বোঝার জন্য এটিই নির্ভরযোগ্য হিসাব। /etc/apt/preferences.d/-এর যেকোনো entry একটি pin। noble-এর জন্য লেখা pin নতুন release-এও পুরোনো package নির্বাচন করতে থাকবে।

প্রতিটি তৃতীয় পক্ষের repository-এর ক্ষেত্রে upgrade শুরু করার আগে নিশ্চিত করুন যে vendor নতুন codename-এর জন্য package প্রকাশ করেছে। Docker-এর suite-গুলোর তালিকা https://download.docker.com/linux/ubuntu/dists/-এ রয়েছে। অন্যান্য vendor-ও একই 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 নিষ্ক্রিয় রাখুন। vendor যে codename-এর জন্য package তৈরি করেছে, সেটি না থাকলে অন্য codename বসিয়ে সম্পাদনা করবেন না। এতে ভুল system library-এর বিরুদ্ধে linked package install হতে পারে।

ধাপ 4: সাধারণ SSH shell-এ নয়, tmux-এ upgrade চালান

সাধারণ login shell-এ do-release-upgrade চলার সময় আপনার connection বিচ্ছিন্ন হলে process SIGHUP পায় এবং unpacking-এর মাঝপথে বন্ধ হয়ে যায়। এতে dpkg আংশিকভাবে configured অবস্থায় থেকে যায়। এমনও হতে পারে যে server-এর network stack আর কাজ করছে না, তাই আবার connection করা সম্ভব হবে না। এর পরিবর্তে 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-এ port খুলে দেওয়া নিরাপদ নয়। শুরু করার আগে নিজে 1022 port খুলুন। sudo ufw delete allow 1022/tcp শেষ হলে port-টি বন্ধ করুন। মনে রাখবেন, আপনার provider server-এর বাইরেও control panel-এ একটি দ্বিতীয় firewall চালাতে পারে।

তারপরও connection বিচ্ছিন্ন হলে আবার login করে tmux attach -t upgrade চালান। আপনি অনুপস্থিত থাকলেও upgrade চলতে থাকে।

ধাপ 5: configuration file-এর prompt-এ ভেবেচিন্তে উত্তর দিন

আপনি বা কোনো script পরিবর্তন করেছে, dpkg শুধু সেই file-গুলোর জন্য prompt দেখায়। তাই প্রতিটি prompt এমন একটি file-এর জন্য, যেটি আপনি ইচ্ছাকৃতভাবে edit করেছেন। prompt সরানোর জন্য 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 রেখে দেওয়ার একটি খরচ আছে: নতুন default-গুলো আপনি পাবেন না। পরে, server চালু হওয়ার পর এবং সময়ের চাপ না থাকলে, দুই version মিলিয়ে নিন।

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

যে file-টি তালিকাভুক্ত হয়, সেটি আপনার file-এর পাশে maintainer-এর version হিসেবে সংরক্ষিত থাকে। একবারে একটি করে diff করুন এবং গুরুত্বপূর্ণ setting-গুলো copy করে নিন। দুটি file-এ অতিরিক্ত সতর্কতা দরকার: /etc/ssh/sshd_config, কারণ ভুল উত্তর দিলে আপনার session শেষ হয়ে যেতে পারে; এবং web server config, কারণ ভুল উত্তর দিলে site-গুলো বন্ধ হয়ে যাবে।

Upgrade-এর সময় needrestart ব্যবহার করে কোন service restart করতে হবে তাও জিজ্ঞাসা করা হয়। সম্পূর্ণ list গ্রহণ করুন। Disk থেকে মুছে ফেলা shared library file ব্যবহার করে কোনো daemon চলতে থাকলে, আপনি যখন তা monitor করছেন না, তখন পরবর্তী কোনো 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-এ শূন্য unit তালিকাভুক্ত হওয়ার কথা; সেখানে যা কিছু তালিকাভুক্ত হবে, সেটিই আপনার পরবর্তী কাজ। সর্বশেষ apt update release image তৈরি হওয়ার পর প্রকাশিত update সংগ্রহ করে।

PostgreSQL 16 থেকে 18: যে cluster নীরবে পিছিয়ে থাকে

Ubuntu 24.04-এ PostgreSQL 16 এবং 26.04-এ PostgreSQL 18 সরবরাহ করা হয়। Upgrade করলে 18, 16-এর পাশে install হয় এবং আপনার data স্থানান্তরিত হয় না। Debian-এর postgresql-common layer নতুন major version-এর জন্য পরের খালি port-এ একটি নতুন empty cluster তৈরি করে। ফলে 16 সব data নিয়ে port 5432 ধরে রাখে, আর 18 port 5433-এ empty অবস্থায় থাকে। আপনার application 5432-এ কথা বলা চালিয়ে যায় এবং কোনো সমস্যা চোখে পড়ে না। এ কারণেই অনেকে বিষয়টি কয়েক মাস পরে আবিষ্কার করেন।

pg_lsclusters

দুটি cluster তালিকাভুক্ত থাকলে বুঝবেন migration হয়নি। Application বন্ধ করা সম্ভব হলে এটি করুন:

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

প্রথমে empty 18 cluster মুছে ফেলুন, কারণ pg_upgradecluster আগে থেকেই থাকা target cluster-এ লিখবে না। Default পদ্ধতিতে 16-এর dump নেওয়া হয় এবং সেটি 18-এ reload করা হয়। তাই database-এর আকারের কাছাকাছি অতিরিক্ত disk space প্রয়োজন হবে। বড় database-এর ক্ষেত্রে -m upgrade এর পরিবর্তে pg_upgrade ব্যবহার করে এবং এটি অনেক দ্রুত। কাজ শেষ হলে Port column পড়ুন। নতুন cluster 5432 দখল করবে এবং পুরোনো cluster stopped অবস্থায় থাকবে। Analyze pass নিজে চালান। নতুন করে load করা cluster-এ statistics থাকে না, তাই প্রথম query-গুলো ধীর হবে।

কয়েক দিন নতুন cluster-এর বিরুদ্ধে application পরীক্ষা করুন। এরপরই শুধু পুরোনো 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-এ upgrade করে, এবং দুটি পরিবর্তনের কারণে server-এ সমস্যা দেখা দেয়।

প্রথমত, mysqld-এর configuration-এ নতুন version-এ সরিয়ে দেওয়া কোনো option থাকলে এটি start হতে অস্বীকার করে। default_authentication_plugin-ই সাধারণত সমস্যা তৈরি করে, কারণ অনেক পুরোনো guide-এ এটি সেট করতে বলা হয়েছে। service ব্যর্থ হয়, এবং journalctl -u mysql -n 50 সরাসরি unknown variable-এর নাম দেখায়। /etc/mysql/mysql.conf.d/-এর অধীনে থাকা file থেকে ওই line মুছে দিন, তারপর sudo systemctl start mysql।

দ্বিতীয়ত, 8.4-এ mysql_native_password plugin আর default হিসেবে enabled থাকে না। তাই কোনো account এখনও এটি ব্যবহার করলে account-টি একেবারেই login করতে পারে না। এখনও 8.0 ব্যবহার করার সময় পরীক্ষা করুন:

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

upgrade-এর আগে mysql_native_password দেখানো প্রতিটি account-এর authentication method পরিবর্তন করুন। এরপর আপনার 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: আপনার vhost এমন একটি socket-এ নির্দেশ করছে, যা আর নেই

24.04-এর সঙ্গে PHP 8.3 এবং 26.04-এর সঙ্গে PHP 8.5 সরবরাহ করা হয়। Package-গুলো version নির্ভর path-এ install হয়, এবং আপনার web server configuration-এ কোনো পরিবর্তন স্বয়ংক্রিয়ভাবে লেখা হয় না। fastcgi_pass unix:/run/php/php8.3-fpm.sock; থাকা একটি nginx vhost এখন এমন একটি socket-এ নির্দেশ করছে, যা কোনো process তৈরি করে না। তাই প্রতিটি PHP request 502 ফেরত দেয় এবং nginx error log-এ দেখা যায়:

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

নতুন socket-এ নির্দেশ করুন, configuration পরীক্ষা করুন এবং 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 জানাবে যে file না থাকায় libphp8.3.so load করা যাচ্ছে না। Enabled module-টি এমন একটি package-এর symlink, যা আর নেই।

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

আপনি যদি Ubuntu 24.04-এ একটি LAMP stack দিয়ে server তৈরি করে থাকেন, তাহলে এই দুই path-ই পরীক্ষা করা উচিত। কারণ guide-টি version নির্ভর module name এবং version নির্ভর socket রেখে যায়।

আপনার php.ini tuning-ও নতুন installation-এ স্থানান্তরিত হয় না। memory_limit, upload_max_filesize এবং আপনার নির্ধারণ করা অন্যান্য setting /etc/php/8.3/-এ থাকে, আর নতুন tree default মান দিয়ে শুরু হয়। দুইটি file-এর মধ্যে diff দেখুন এবং মানগুলো হাতে করে স্থানান্তর করুন। পুরো পুরোনো file-টি নতুনটির ওপর copy করলে 8.3-এর default মানগুলো 8.5 installation-এ চলে আসে। এরপর php -m চালিয়ে তুলনা করুন। php8.3-redis হিসেবে install করা extension-এর জন্য তার php8.5- package প্রয়োজন। আর extension-টি PPA থেকে এলে upgrader সেই source disable করে থাকতে পারে, ফলে extension-টি অনুপস্থিত থাকবে।

Certificate-এর জন্য আলাদা একটি পরীক্ষা করা উচিত। Upgrade-এর পরে sudo certbot renew --dry-run চালান। এটি live certificate পরিবর্তন না করেই renewal path-এর সম্পূর্ণ প্রক্রিয়া পরীক্ষা করে, যার মধ্যে web server reload hook-ও রয়েছে। কোনো hook service name বা পরিবর্তিত binary ব্যবহার করলে সেটি 60 দিনের মধ্যে নীরবে ব্যর্থ হওয়ার বদলে এখানেই আপনার সামনে ব্যর্থ হবে। nginx-এ Let's Encrypt সহ Certbot-এ এই hook-গুলো কেমন হওয়া উচিত তা ব্যাখ্যা করা হয়েছে।

SSH: যে ত্রুটি আপনার বর্তমান session বন্ধ করে দেয়

sshd_config prompt-এই মানুষ নিজেদের system থেকে access হারান। Y-এর উত্তর দিলে maintainer-এর file install হয়। এতে আপনার PermitRootLogin, PasswordAuthentication, AllowUsers, Port এবং আপনার যোগ করা অন্য সব line বাদ পড়ে। আপনার firewall যদি শুধু custom port অনুমোদন করে এবং packaged config 22 port-এ listening করে, তাহলে পরের connection প্রত্যাখ্যাত হবে। আপনি যে session-এ আছেন, সেটিই তখন আপনার শেষ session।

upgrade করার আগে এটি প্রতিরোধ করুন। 24.04-এ /etc/ssh/sshd_config, Include /etc/ssh/sshd_config.d/*.conf দিয়ে শুরু হয়। OpenSSH প্রতিটি setting-এর জন্য পড়া প্রথম value-টি ব্যবহার করে। তাই শুরুতে include করা drop-in নিচের সবকিছুর ওপর কার্যকর হয়। আপনার 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-এর জন্য আরও একটি পরীক্ষা দরকার, কারণ port-টি আপনার ধারণার জায়গায় নাও থাকতে পারে:

systemctl is-enabled ssh.socket

এটি enabled দেখালে listening port-এর মালিক systemd। তাই sshd_config-এর Port line উপেক্ষা করা হয়। Ubuntu 22.10 থেকে sshd-এর জন্য socket activation ব্যবহার করে। তাই Port 2222 সম্পাদনা করেও কোনো পরিবর্তন দেখা যায় না। sudo systemctl edit ssh.socket ব্যবহার করে পরিবর্তনটি socket unit-এ সেট করুন:

[Socket]
ListenStream=
ListenStream=2222

খালি ListenStream= প্রয়োজনীয়। এটি উত্তরাধিকারসূত্রে পাওয়া value মুছে দেয়। এটি না থাকলে socket 22 এবং 2222—দুই port-এই 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)'

এরপর নিজের computer-এ একটি দ্বিতীয় terminal খুলে আবার login করুন। দ্বিতীয় terminal-এ কার্যকর shell পাওয়াই একমাত্র নির্ভরযোগ্য প্রমাণ। এটি নিশ্চিত না হওয়া পর্যন্ত প্রথম session খোলা রাখুন। VPS-এ SSH hardening এই drop-in-এ রাখার মতো settings ব্যাখ্যা করে।

যদি ইতিমধ্যে দেরি হয়ে যায়, আপনার provider-এর web console এমন একটি login দেয়, যা SSH ব্যবহার করে না। সেখানে login করে config ঠিক করুন, sudo sshd -t চালান এবং service restart করুন। upgrade-এর সময় নয়, তার আগে console access পরীক্ষা করার কারণ এটাই।

FAQ

Ubuntu 24.04-এ do-release-upgrade কেন "No new release found" দেখায়?

কারণ Ubuntu Server-এ /etc/update-manager/release-upgrades-এ Prompt=lts সেট করা আছে। এই সেটিং পরবর্তী long term support release-এর প্রথম point release প্রকাশিত হওয়ার পর সেটি দেখায়। Ubuntu 26.04 LTS 23 April 2026-এ প্রকাশিত হয়েছে, এবং 26.04.1-এর নির্ধারিত তারিখ 27 August 2026। সেই দিন পর্যন্ত 24.04 server কোনো নতুন release দেখতে পাবে না। এই সেটিং অপরিবর্তিত রাখুন। Prompt=normal-এ পরিবর্তন করবেন না, কারণ এতে আপনি interim release-গুলোর মধ্য দিয়ে upgrade করবেন।

Upgrade সম্পন্ন করতে কি server reboot করতেই হবে?

হ্যাঁ। Upgrade-এর সময় নতুন kernel, নতুন C library এবং নতুন init system ইনস্টল হয়। System restart না হওয়া পর্যন্ত চলমান system পুরোনোগুলোই ব্যবহার করে। শেষে do-release-upgrade reboot করতে বলে। "later" পর্যন্ত চালু রাখা machine-এ দুইটি release-এর মিশ্রণ চলতে থাকে। Server ফিরে আসার পর নতুন kernel-এর জন্য uname -r এবং যেসব service চালু অবস্থায় টিকে থাকেনি সেগুলোর জন্য systemctl --failed পরীক্ষা করুন।

In-place upgrade করা উচিত, নাকি নতুন 26.04 server তৈরি করা উচিত?

সম্ভব হলে নতুন server তৈরি করুন। নতুন VPS-এ পুরোনো server চালু রেখেই stack install, data restore এবং সবকিছু পরীক্ষা করা যায়। ফলে rollback backup restore করার পরিবর্তে DNS পরিবর্তন করার পর্যায়ে থাকে। Server-এ সরানো কঠিন state থাকলে, provider প্রতি machine অনুযায়ী billing করলে, অথবা আপনার snapshot ও পরীক্ষিত console access থাকলে in-place upgrade করুন। In-place পদ্ধতিটি প্রচলিত এবং পরীক্ষিত, তবে এটি চলাকালীন এক ঘণ্টার জন্য কার্যত একমুখী পরিবর্তন।

Upgrade চলাকালে SSH connection বিচ্ছিন্ন হলে কী হয়?

সাধারণ login shell-এ process SIGHUP পায় এবং মাঝপথে বন্ধ হয়ে যায়। এতে dpkg আংশিকভাবে configured অবস্থায় থেকে যায়। tmux অথবা screen-এর ভিতরে process চালু করুন। তাহলে process চলতে থাকে, এবং আবার সংযোগ করে tmux attach -t upgrade চালিয়ে upgrade পুনরায় শুরু করতে পারবেন। Upgrader দ্বিতীয় প্রবেশপথ হিসেবে port 1022-এ একটি অতিরিক্ত SSH daemon-ও চালু করে। তবে ওই port-এর জন্য firewall rule তৈরি করে না। তাই আগে নিজে 1022 অনুমোদন করুন এবং পরে সেটি বন্ধ করুন।

Upgrade-এর পরে আমার PHP site 502 দেখাচ্ছে। কী নষ্ট হয়েছে?

PHP FPM socket path version-এর সঙ্গে পরিবর্তিত হয়েছে। Ubuntu 24.04-এ PHP 8.3 এবং 26.04-এ PHP 8.5 চলে। তাই আপনার nginx vhost এখনও পুরোনো path উল্লেখ করলেও /run/php/php8.3-fpm.sock আর বিদ্যমান নেই। nginx error log-এ connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) দেখা যাবে। fastcgi_pass-এ 8.5 socket সেট করুন, sudo nginx -t চালান, তারপর nginx reload করুন। Apache-এ mod_php ব্যবহার করলে সমতুল্য সমাধান হলো sudo a2dismod php8.3 চালিয়ে sudo a2enmod php8.5 এবং restart করা।