VPS वर Ubuntu 24.04 चे 26.04 वर अपग्रेड कधी?

Ubuntu 24.04 चे 26.04 वर अपग्रेड कधी करता येईल?

26.04.1 point release प्रसिद्ध झाल्यानंतर VPS वरील Ubuntu 24.04 चे 26.04 वर अपग्रेड करता येईल. हे प्रकाशन 27 August 2026 रोजी नियोजित आहे. तोपर्यंत 24.04 सर्व्हरला नवीन release दिसणार नाही. हे जाणीवपूर्वक केले जाते. Ubuntu 26.04 LTS (Resolute Raccoon) 23 April 2026 रोजी प्रसिद्ध झाले. परंतु Canonical पहिल्या point release नंतरच LTS ते LTS अपग्रेड मार्ग उपलब्ध करते. कारण पहिल्या काही महिन्यांत आढळलेल्या installation आणि upgrade त्रुटी त्या release मध्ये समाविष्ट केल्या जातात.

August 2026 च्या सुरुवातीला 24.04 मशीनवर तपासणी चालवल्यास पुढील परिणाम मिळतो:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

ही तुमच्या सर्व्हरवरील त्रुटी नाही. /etc/update-manager/release-upgrades मध्ये Ubuntu Server वरील Prompt=lts समाविष्ट आहे. याचा अर्थ हे साधन फक्त पुढील long term support release देऊ करते आणि त्यासाठीचा .1 point release उपलब्ध झाल्यानंतरच ते तसे करते. Prompt=normal सेट केल्यास 24.10, 25.04 आणि 25.10 या क्रमाने अपग्रेड करण्याची प्रक्रिया सुरू होईल. हे interim releases आता सर्व end of life झाले आहेत. lts तसेच ठेवून प्रतीक्षा करा. Canonical च्या schedule मधील तारखा बदलू शकतात. त्यामुळे तो दिवस शांतपणे निघून गेल्यास पुन्हा तपासणी करा.

खालील प्रत्येक command तुम्ही स्वतःच्या सर्व्हरवर, दिलेल्या क्रमाने, स्वतः चालवायचा आहे. ज्या मशीनचे अपग्रेड सुरू आहे त्यावर release upgrade ची पूर्वतालीम करता येत नाही. या प्रक्रियेत kernel आणि C library बदलली जातात. ती पूर्ण करण्यासाठी reboot आवश्यक असतो.

सुधारणा करावीच का?

Ubuntu 24.04 ला 2029 पर्यंत नियमित सुरक्षा अद्यतने मिळतात. त्यामुळे कार्यरत production server साठी तातडीची आवश्यकता नाही. 26.04 मध्ये उपलब्ध असलेली एखादी सुविधा हवी असल्यास सुधारणा करा: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 किंवा 7.0 kernel. "क्रमांक वाढला" हे ग्राहकांना सेवा देणाऱ्या machine मध्ये बदल करण्याचे कारण नाही.

खालीलपैकी कोणतीही बाब लागू असल्यास in-place upgrade करू नका:

• तुम्ही तुमच्या provider चे console (VNC किंवा serial) कधीही उघडलेले नाही आणि त्यातून login केलेले नाही. SSH मध्ये बिघाड झाल्यास server मध्ये पुन्हा प्रवेश मिळवण्याचा तो एकमेव मार्ग असतो. तुम्ही बाहेर अडकलेले असताना console काम करत नाही हे समजणे उशिराचे ठरते.
• तुम्हाला एका तासाचा downtime परवडत नाही आणि rollback ची व्यवस्था नाही.
• तुमचा stack अशा third-party repository वर अवलंबून आहे, ज्याने अद्याप resolute साठी package प्रकाशित केलेले नाही.
• server दोन वर्षांपूर्वी हाताने तयार केला होता आणि त्यावर काय आहे हे कोणालाही माहीत नाही.

अशा वेळी पर्यायी मार्ग अधिक चांगला असतो: नवीन 26.04 VPS तयार करा, त्यावर तुमचा stack install करा आणि data restore करा. नवीन server योग्य प्रकारे उत्तर देत असल्याची खात्री झाल्यावर DNS बदला. नवीन server स्वतःची क्षमता सिद्ध करेपर्यंत जुना server चालू ठेवता येतो. त्यामुळे rollback साठी restore करण्याऐवजी DNS बदलणे पुरेसे ठरते. हा मार्ग निवडल्यास नवीन VPS वरील पहिले दहा मिनिटे येथून सुरुवात करा आणि नवीन server योग्य पद्धतीने तयार करा.

पायरी 1: पुनर्संचयित करता येईल असा बॅकअप घ्या

दोन स्तर वापरा, कारण ते वेगवेगळ्या प्रकारे अपयशी ठरतात. Provider snapshot संपूर्ण disk समाविष्ट करतो आणि काही मिनिटांत पुनर्संचयित करता येतो. मात्र, database मध्ये लेखन सुरू असतानाच तो घेतला जातो. त्यामुळे तो application-consistent नसून crash-consistent असतो. सर्व्हरबाहेर साठवलेला restic वापरून घेतलेल्या file-level backup मधून स्वतंत्र files मिळतात. तुमचे account lock झाले तरी त्याची प्रत उपलब्ध राहते.

सर्वप्रथम databases manually 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 प्रत्यक्षात तुम्ही आधी वापराल, कारण upgrade दरम्यान विचारल्या जाणाऱ्या प्रत्येक config file ची प्रत त्यात असते.

ज्याचा restore कधीच करून पाहिलेला नाही, असा backup म्हणजे केवळ अंदाज आहे. गरज पडण्यापूर्वीच, आत्ताच त्यातून एक file बाहेर काढून पाहा.

पायरी 2: प्रथम 24.04 पूर्णपणे patch करा

पॅकेजची स्थिती बिघडलेली असल्यास do-release-upgrade चालण्यास नकार देते. अर्धवट patch केलेल्या 24.04 मुळे त्यानंतरच्या प्रत्येक त्रुटीचे कारण समजणे अधिक कठीण होते.

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

dpkg --audit ने काहीही output न दिल्यास कोणतेही पॅकेज अर्धवट configure केलेले नाही. apt-mark showhold ने काहीही output न दिल्यास upgrade रोखेल अशा version वर कोणतेही पॅकेज pinned केलेले नाही. sudo apt-mark unhold आणि पॅकेजचे नाव वापरून सूचीतील प्रत्येक पॅकेज release करा. किंवा hold असण्यामागे कारण आहे असे मानून येथेच थांबा.

Kernel बदलला असल्यास reboot करा. त्यामुळे सध्या मशीन ज्या code वर चालत आहे त्यावरूनच upgrade होईल.

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

त्यानंतर disk space तपासा. काहीही install करण्यापूर्वी upgrader नवीन पॅकेज संच पूर्णपणे download करतो. पुरेशी जागा नसल्यास filesystem चे नाव सांगणारा message देऊन प्रक्रिया थांबते.

df -h / /boot

/ वर सुमारे 5 GB पेक्षा कमी जागा मोकळी असल्यास ही समस्या उद्भवते. /boot ची मोकळी जागा 300 MB पेक्षा कमी असल्यास kernel install दरम्यान पुढे No space left on device सह प्रक्रिया अयशस्वी होते. याचे सामान्य कारण जुने kernels असतात. sudo apt --purge autoremove ते काढून टाकते.

सुरू करण्यापूर्वी आणखी एक गोष्ट थांबवा: स्वयंचलित सुरक्षा अद्यतने प्रक्रियेदरम्यान सुरू झाल्यास ती dpkg lock धरून ठेवतात आणि release upgrader Could not get lock /var/lib/dpkg/lock-frontend सह थांबतो. प्रथम sudo systemctl stop unattended-upgrades चालवा आणि ते पूर्ण झाल्यावर पुन्हा प्रक्रिया सुरू करा.

पायरी 3: तृतीय-पक्ष repositories आणि pinned packages तपासा

do-release-upgrade Ubuntu च्या नसलेल्या प्रत्येक apt source ला अक्षम करते, कारण noble साठी तयार केलेले package resolute system मध्ये बिघाड करू शकते. ती ओळखू शकणाऱ्या sources नंतर पुन्हा सक्षम करते आणि उर्वरित sources comment करून ठेवते. 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 मध्ये दोन formats वापरते: जुने one-line .list files आणि Types: व Suites: fields असलेले deb822 .sources files. Upgrade प्रक्रियेदरम्यान दोन्ही अक्षम केले जातात. कोणत्याही Ubuntu archive मध्ये उपलब्ध नसलेल्या installed packages ची यादी ubuntu-security-status --thirdparty देते. तुम्ही system वर जोडलेल्या packages ची ही अचूक संख्या आहे. /etc/apt/preferences.d/ मधील कोणतीही नोंद pin असते. noble साठी लिहिलेला pin नवीन release मध्येही जुने package निवडत राहील.

प्रत्येक तृतीय-पक्ष repository साठी, प्रक्रिया सुरू करण्यापूर्वी vendor ने नवीन codename साठी repository प्रकाशित केली आहे याची खात्री करा. 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 ने repository प्रकाशित करेपर्यंत ती source अक्षमच ठेवा. Vendor ने तयार केलेल्या suite ऐवजी दुसऱ्या suite चे codename संपादित केल्यास चुकीच्या system libraries शी जोडलेली packages install होतात.

पायरी 4: साध्या SSH shell ऐवजी upgrade tmux मध्ये चालवा

साध्या login shell मध्ये do-release-upgrade चालू असताना तुमचे connection तुटले, तर process ला SIGHUP मिळतो आणि unpacking अर्धवट असताना तो बंद होतो. त्यामुळे dpkg अर्धवट configured राहतो आणि पुन्हा connect करण्यासाठी कार्यरत network stack नसलेला server तयार होऊ शकतो. त्याऐवजी ते 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 दुसरा SSH daemon port 1022 वर सुरू करतो आणि हे स्पष्टपणे सांगतो:

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 server च्या बाहेर, त्याच्या control panel मध्ये, दुसरा firewall चालवत असू शकतो हे लक्षात ठेवा.

तरीही connection तुटल्यास पुन्हा login करा आणि tmux attach -t upgrade चालवा. तुम्ही disconnect असताना upgrade चालू राहिले होते.

पायरी 5: configuration file संदर्भातील प्रश्नांचा विचारपूर्वक निर्णय घ्या

dpkg केवळ तुम्ही किंवा एखाद्या script ने बदललेल्या files संदर्भातच प्रश्न विचारते. त्यामुळे प्रत्येक prompt हा तुम्ही जाणीवपूर्वक edit केलेल्या file साठी असतो. तो 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 वापरून तुमची आवृत्ती कायम ठेवा. Default आधीच N असतो. हे सुरक्षित उत्तर आहे, कारण तुमची file सध्या कार्यरत आहे आणि packaged file या machine वर यापूर्वी कधीही चालवली गेलेली नाही.

तुमची file कायम ठेवल्यास त्याची किंमत असते: तुम्हाला नवीन defaults मिळत नाहीत. नंतर, system सुरू झाल्यावर आणि तुमच्यावर वेळेचा दबाव नसताना, दोन्ही configuration एकत्रित करा.

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

यादी दाखवणारी प्रत्येक file maintainer ची आवृत्ती असते आणि ती तुमच्या file शेजारी save केलेली असते. त्या files एकावेळी एक अशा प्रकारे diff करा आणि महत्त्वाच्या settings तुमच्या file मध्ये समाविष्ट करा. दोन files कडे विशेष काळजीपूर्वक पाहा: /etc/ssh/sshd_config, कारण चुकीचे उत्तर तुमचे session संपवू शकते; आणि तुमची web server config, कारण चुकीचे उत्तर websites बंद करू शकते.

Upgrade प्रक्रियेत needrestart द्वारे कोणत्या services restart करायच्या आहेत हेही विचारले जाते. संपूर्ण यादी स्वीकारा. Disk वरून delete केलेल्या shared library file विरुद्ध अजूनही चालू असलेला daemon नंतरच्या एखाद्या request वेळी crash होऊ शकतो. त्या वेळी तुम्ही त्याचे monitoring करत नसण्याची शक्यता असते.

पायरी 6: रीबूट करा आणि मशीन तपासा

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 ची यादी दिसली पाहिजे. त्यात कोणतीही unit दिसल्यास, ती तुमची पुढील तपासणी आहे. अंतिम apt update मुळे release images तयार केल्यानंतर प्रकाशित झालेली updates मिळतात.

PostgreSQL 16 ते 18: शांतपणे मागे राहणारा cluster

Ubuntu 24.04 मध्ये PostgreSQL 16 आणि 26.04 मध्ये PostgreSQL 18 release होते. Upgrade प्रक्रियेत PostgreSQL 18 हे PostgreSQL 16 च्या शेजारी install होते आणि तुमचा data हलवला जात नाही. Debian चा postgresql-common layer नवीन major version साठी पुढील मोकळ्या port वर नवीन रिकामा cluster तयार करतो. त्यामुळे PostgreSQL 16 तुमचा सर्व data घेऊन port 5432 वरच राहतो आणि PostgreSQL 18 port 5433 वर रिकामा असतो. तुमचा application port 5432 शीच संवाद साधत राहतो आणि काहीही चुकीचे दिसत नाही. म्हणून ही बाब अनेकदा काही महिन्यांनी लक्षात येते.

pg_lsclusters

दोन clusters सूचीमध्ये दिसत असतील, तर migration झालेली नाही. Application थांबवता येईल तेव्हा migration करा:

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

सर्वप्रथम रिकामा PostgreSQL 18 cluster drop करा, कारण आधीपासून अस्तित्वात असलेल्या target cluster मध्ये pg_upgradecluster लिहिणार नाही. Default पद्धतीत PostgreSQL 16 चा dump घेऊन तो PostgreSQL 18 मध्ये reload केला जातो. त्यामुळे database च्या आकाराएवढी साधारणपणे मोकळी disk space आवश्यक असते. मोठ्या database साठी -m upgrade ऐवजी pg_upgrade वापरते आणि ही पद्धत अधिक वेगवान असते. प्रक्रिया पूर्ण झाल्यावर Port column वाचा. नवीन cluster port 5432 स्वीकारतो आणि जुना cluster stopped स्थितीत ठेवला जातो. Analyze pass स्वतः चालवा, कारण नुकताच load केलेल्या cluster मध्ये statistics नसतात आणि सुरुवातीच्या queries slow असतात.

काही दिवस application ची चाचणी नवीन cluster विरुद्ध करा. त्यानंतरच जुना cluster काढून टाका:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

जुन्या cluster ची data directory हा तुमच्याकडे असलेला सर्वात जलद rollback पर्याय आहे. Upgrade च्या दिवशी ती delete करू नका.

MySQL 8.0 ते 8.4: काढलेला पर्याय जो सर्व्हर सुरू होण्यापासून थांबवतो

26.04 मध्ये MySQL 8.0 वरून 8.4 LTS वर जाते आणि दोन बदल सर्व्हरमध्ये समस्या निर्माण करतात.

पहिले, configuration मध्ये नवीन आवृत्तीने काढलेला पर्याय असल्यास mysqld सुरू होण्यास नकार देते. default_authentication_plugin हा सर्वसाधारण पर्याय आहे, कारण अनेक जुन्या मार्गदर्शकांमध्ये तो सेट करण्यास सांगितले आहे. सेवा अयशस्वी होते आणि journalctl -u mysql -n 50 अज्ञात variable चे नाव थेट दाखवते. /etc/mysql/mysql.conf.d/ अंतर्गत असलेल्या file मधून ती line काढा, नंतर sudo systemctl start mysql.

दुसरे, 8.4 मध्ये mysql_native_password plugin default ने enabled नसतो. त्यामुळे तो अजूनही वापरणारे account login करू शकत नाही. तुम्ही अजून 8.0 वर असतानाच तपासा:

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

mysql_native_password दाखवणारे प्रत्येक account upgrade करण्यापूर्वी migrate करा. त्यानंतर तुमच्या 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: तुमचे vhost आता अस्तित्वात नसलेल्या socket कडे निर्देश करतात

24.04 मध्ये PHP 8.3 आणि 26.04 मध्ये PHP 8.5 उपलब्ध होते. Packages versioned paths मध्ये 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 अजिबात सुरू होत नाही आणि 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 तयार केला असेल, तर हे दोन्ही paths तपासा. त्या guide मुळे versioned module name आणि versioned socket configuration मध्ये राहतात.

तुमचे php.ini tuning देखील आपोआप पुढे येत नाही. memory_limit, upload_max_filesize आणि तुम्ही सेट केलेल्या इतर सर्व values /etc/php/8.3/ मध्ये असतात. नवीन tree defaults पासून सुरू होते. दोन्ही files मधील फरक पाहा आणि values manually कॉपी करा. जुनी file पूर्णपणे नवीन file वर कॉपी केल्यास 8.3 चे defaults 8.5 install मध्ये येतात. त्यानंतर php -m चालवून तुलना करा. php8.3-redis म्हणून install केलेल्या extension साठी php8.5- package आवश्यक असते. ते PPA मधून आले असेल, तर upgrader ने तो source disable केलेला असू शकतो आणि extension थेट missing असते.

Certificates साठी स्वतंत्रपणे एक तपासणी करा. Upgrade नंतर sudo certbot renew --dry-run चालवा. हा command live certificate मध्ये बदल न करता संपूर्ण renewal path तपासतो. यात web server reload hook देखील तपासला जातो. एखादा hook बदललेल्या service name किंवा binary ला call करत असेल, तर तो इथे तुमच्यासमोर fail होतो; 60 दिवसांनी शांतपणे fail होत नाही. nginx वर Let's Encrypt सह Certbot मध्ये हे hooks कसे दिसायला हवेत ते स्पष्ट केले आहे.

SSH: तुम्ही वापरत असलेले session संपवणारी त्रुटी

sshd_config prompt मुळे अनेकदा वापरकर्ते स्वतःलाच सर्व्हरबाहेर लॉक करतात. Y ला उत्तर दिल्यास maintainer ची file स्थापित होते. त्यामुळे तुमची PermitRootLogin, PasswordAuthentication, AllowUsers, Port आणि तुम्ही जोडलेल्या इतर सर्व ओळी हटतात. तुमच्या firewall मध्ये केवळ custom port ला परवानगी असेल आणि packaged config 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 खालील कोणत्याही setting वर प्राधान्य मिळवते. तुमच्या 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 ओळ दुर्लक्षित केली जाते. Ubuntu ने 22.10 पासून sshd साठी socket activation वापरले आहे. त्यामुळे Port 2222 मधील बदलाचा कोणताही परिणाम दिसत नाही. sudo systemctl edit ssh.socket वापरून ही setting socket unit वर करा:

[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)'

त्यानंतर तुमच्या स्वतःच्या मशीनवर दुसरे terminal उघडा आणि पुन्हा login करा. त्या दुसऱ्या terminal मधील कार्यरत shell हाच ग्राह्य पुरावा आहे. ते मिळेपर्यंत पहिले session उघडे ठेवा. VPS वरील SSH hardening मध्ये त्या drop-in मध्ये ठेवण्यासारख्या settings दिल्या आहेत.

आता उशीर झाला असेल, तर तुमच्या provider चे web console SSH न वापरता login करण्याची सुविधा देते. तेथे login करा, config दुरुस्त करा, sudo sshd -t चालवा आणि service restart करा. upgrade सुरू असताना नव्हे, तर 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 उपलब्ध झाल्यानंतरच ती release दाखवते. Ubuntu 26.04 LTS 23 April 2026 रोजी release झाले आणि 26.04.1 27 August 2026 रोजी scheduled आहे. त्या दिवसापर्यंत 24.04 सर्व्हरला कोणतीही नवीन release दिसणार नाही. Prompt=normal वर स्विच करण्याऐवजी सध्याची सेटिंग तशीच ठेवा. Prompt=normal निवडल्यास upgrade interim releases मधून केले जाईल.

Upgrade पूर्ण करण्यासाठी सर्व्हर reboot करावा लागतो का?

होय. Upgrade नवीन kernel, नवीन C library आणि नवीन init system install करते. सर्व्हर restart होईपर्यंत चालू system जुने घटक वापरत राहते. do-release-upgrade शेवटी reboot करण्यास सांगते. सर्व्हर “नंतर” reboot करण्यासाठी चालू ठेवला, तर तो दोन releases चे मिश्रण वापरत राहतो. सर्व्हर पुन्हा सुरू झाल्यानंतर नवीन kernel साठी uname -r तपासा आणि reboot नंतर सुरू न झालेल्या सेवांसाठी systemctl --failed तपासा.

सर्व्हर in place upgrade करावा की नवीन 26.04 सर्व्हर तयार करावा?

शक्य असल्यास नवीन सर्व्हर तयार करा. नवीन VPS मध्ये जुना सर्व्हर अजूनही network traffic देत असताना stack install करून data restore करता येतो आणि सर्वकाही तपासता येते. त्यामुळे rollback साठी backup restore करण्याऐवजी DNS बदलणे पुरेसे असते. सर्व्हरवरील state दुसरीकडे हलवणे कठीण असल्यास, provider प्रत्येक machine साठी शुल्क आकारत असल्यास किंवा snapshot आणि console access ची चाचणी केलेली असल्यास in-place upgrade करा. In-place upgrade ची प्रक्रिया परिचित आहे; परंतु ती सुरू झाल्यानंतर त्या एका तासासाठी ती एकतर्फी प्रक्रिया असते.

Upgrade दरम्यान माझे SSH connection तुटल्यास काय होते?

साध्या login shell मध्ये process ला SIGHUP मिळतो आणि तो मध्येच बंद होतो. त्यामुळे dpkg अर्धवट configured राहते. Process tmux किंवा screen च्या आत सुरू करा. त्यामुळे process चालू राहतो. पुन्हा connect झाल्यानंतर tmux attach -t upgrade चालवून upgrade पुढे सुरू करा. Upgrader port 1022 वर spare SSH daemon देखील सुरू करतो. हा port firewall मध्ये आपोआप उघडला जात नाही. त्यामुळे आधी स्वतः 1022 ला परवानगी द्या आणि काम पूर्ण झाल्यावर तो port बंद करा.

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 path द्या आणि sudo nginx -t चालवा. त्यानंतर nginx reload करा. Apache वर mod_php वापरत असल्यास समतुल्य दुरुस्ती म्हणजे sudo a2dismod php8.3 चालवणे, त्यानंतर sudo a2enmod php8.5 चालवून Apache restart करणे.