Ubuntu 24.04 वरून 26.04 VPS upgrade कधी करावे?

Ubuntu 24.04 वरून 26.04 वर कधी upgrade करता येईल?

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

August 2026 च्या सुरुवातीला 24.04 box वर check चालवल्यास पुढील output मिळेल:

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 सेट केल्यास 24.10, 25.04 आणि 25.10 या interim releases मधून क्रमाने upgrade केले जाईल. या सर्व 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 करण्याची आवश्यकता नाही. 26.04 मध्ये उपलब्ध असलेली एखादी गोष्ट हवी असेल, तर upgrade करा: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 किंवा 7.0 kernel. "नंबर वाढला आहे" हे ग्राहकांना सेवा देणाऱ्या मशीनमध्ये बदल करण्याचे कारण नाही.

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

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

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

पायरी 1: ज्या backup मधून restore करता येईल असा backup घ्या

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

सर्वप्रथम databases चा dump manually घ्या. 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 विषयी प्रश्न विचारले जाणार आहेत त्या त्यात असतात.

ज्या backup मधून तुम्ही कधीही 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 रोखणाऱ्या आवृत्तीवर कोणतेही पॅकेज pinned केलेले नाही. sudo apt-mark unhold आणि पॅकेजचे नाव वापरून सूचीतील प्रत्येक hold काढा. किंवा तो hold जाणूनबुजून ठेवलेला आहे असे मानून येथेच थांबा.

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

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

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

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 sources निष्क्रिय करते, कारण noble साठी build केलेले package resolute system मध्ये समस्या निर्माण करू शकते. ते नंतर ओळखलेले sources पुन्हा सक्षम करते आणि उर्वरित sources comment out ठेवते. Tool तुमच्यासाठी निर्णय घेण्यापूर्वी तुम्ही कोणते packages वापरत आहात हे जाणून घ्या.

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 देते. तुम्ही अतिरिक्तपणे जोडलेल्या packages ची ही अचूक संख्या आहे. /etc/apt/preferences.d/ मधील कोणतीही entry ही pin असते. noble साठी लिहिलेली pin नवीन release मध्येही जुने package निवडत राहील.

प्रत्येक तृतीय-पक्ष repository साठी, प्रक्रिया सुरू करण्यापूर्वी vendor ने नवीन codename साठी package प्रकाशित केले आहे याची खात्री करा. Docker चे suites https://download.docker.com/linux/ubuntu/dists/ येथे सूचीबद्ध आहेत. इतर vendors देखील अशीच directory उपलब्ध करून देतात. अस्तित्वात नसलेल्या suite कडे निर्देश करणारा source असल्यास upgrade नंतरच्या पहिल्या apt update वेळी खालील संदेश दिसतो:

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

Vendor ने package प्रकाशित करेपर्यंत तो source निष्क्रिय ठेवा. Vendor ने ज्या codename साठी packages build केले आहे त्याऐवजी दुसरा codename लिहिल्यास चुकीच्या system libraries शी linked असलेली packages install होतात.

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

साध्या login shell मध्ये do-release-upgrade चालू असताना तुमचे connection तुटल्यास, process ला SIGHUP मिळतो आणि unpacking पूर्ण होण्यापूर्वी तो बंद होतो. त्यामुळे dpkg अर्धवट configure राहते आणि पुन्हा 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 मध्ये rule उघडत नाही, कारण विचारणा न करता firewall मध्ये मार्ग उघडणे अनपेक्षित आणि अयोग्य ठरेल. सुरुवात करण्यापूर्वी 1022 साठीचा port स्वतः उघडा आणि sudo ufw delete allow 1022/tcp पूर्ण झाल्यावर तो बंद करा. तुमचा provider server च्या बाहेरील control panel मध्ये दुसरा firewall चालवत असू शकतो, हे लक्षात ठेवा.

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

पायरी 5: configuration file prompts विचारपूर्वक हाताळा

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

तुमची file ठेवण्याची किंमत आहे: तुम्हाला नवीन defaults मिळत नाहीत. नंतर reconciliation करा. Machine सुरू झाल्यानंतर आणि तुमच्यावर वेळेचा दबाव नसताना हे करा.

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

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

Upgrade प्रक्रियेत needrestart द्वारे कोणत्या services restart करायच्या आहेत, असेही विचारले जाते. पूर्ण list स्वीकारा. 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 दाखवले पाहिजेत. त्यात काहीही सूचीबद्ध असल्यास, ते तुमचे पुढील काम आहे. शेवटचा apt update release images तयार झाल्यानंतर प्रकाशित झालेली updates आणतो.

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

Ubuntu 24.04 मध्ये PostgreSQL 16 आणि 26.04 मध्ये PostgreSQL 18 release होते. Upgrade प्रक्रियेत 18 हे 16 च्या शेजारी install होते आणि तुमचा data हलवला जात नाही. Debian चा postgresql-common layer नवीन major version साठी पुढील उपलब्ध port वर नवीन रिकामा cluster तयार करतो. त्यामुळे 16 सर्व data सह port 5432 वर सुरू राहतो आणि 18 रिकामा 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 करा, कारण आधीपासून अस्तित्वात असलेल्या target cluster मध्ये pg_upgradecluster लिहिणार नाही. Default पद्धत 16 मधील data dump करून तो 18 मध्ये पुन्हा load करते. त्यामुळे database च्या आकाराएवढी अंदाजे मोकळी disk space आवश्यक आहे. मोठ्या database वर -m upgrade त्याऐवजी pg_upgrade वापरते आणि ही प्रक्रिया अधिक वेगाने पूर्ण होते. प्रक्रिया पूर्ण झाल्यावर Port column वाचा. नवीन cluster 5432 ताब्यात घेतो आणि जुना cluster stopped स्थितीत राहतो. Analyze pass स्वतः चालवा, कारण नव्याने load केलेल्या cluster मध्ये statistics नसतात आणि सुरुवातीच्या queries मंद असतात.

काही दिवस नवीन cluster विरुद्ध application तपासा. त्यानंतरच जुना 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 मधून ती ओळ हटवा आणि नंतर sudo systemctl start mysql.

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

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 करू शकता. ही तात्पुरती bridge म्हणून वापरा आणि तिची समाप्ती तारीख निश्चित करा, कारण हा plugin पूर्णपणे काढून टाकण्याच्या प्रक्रियेत आहे.

PHP 8.3 ते 8.5: तुमचे vhost अस्तित्वात नसलेल्या socket कडे निर्देश करतात

24.04 मध्ये PHP 8.3 आणि 26.04 मध्ये PHP 8.5 उपलब्ध होते. पॅकेजेस versioned paths मध्ये install होतात आणि तुमच्या web server configuration मध्ये कोणताही बदल आपोआप केला जात नाही. fastcgi_pass unix:/run/php/php8.3-fpm.sock; असलेला nginx vhost आता कोणताही process तयार करत नसलेल्या socket कडे निर्देश करतो. त्यामुळे प्रत्येक 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 तपासणे आवश्यक आहे. त्या मार्गदर्शकामुळे versioned module name आणि versioned socket configuration मध्ये राहतात.

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

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

SSH: तुम्ही कार्यरत असलेले सत्र समाप्त करणारे अपयश

sshd_config प्रॉम्प्टमध्ये लोक स्वतःलाच सर्व्हरबाहेर लॉक करून घेतात. Y ला उत्तर दिल्यास maintainers ची फाइल स्थापित होते. त्यामुळे तुमचे PermitRootLogin, PasswordAuthentication, AllowUsers, Port आणि तुम्ही जोडलेल्या इतर सर्व ओळी काढून टाकल्या जातात. तुमच्या firewall मध्ये फक्त custom port ला परवानगी असेल आणि packaged configuration 22 वर listen करत असेल, तर पुढील connection नाकारले जाईल. तुम्ही ज्या session मध्ये आहात ते तुमच्याकडे उरलेले शेवटचे session असेल.

अपग्रेड करण्यापूर्वी हे टाळा. 24.04 वरील /etc/ssh/sshd_config ची सुरुवात Include /etc/ssh/sshd_config.d/*.conf पासून होते. OpenSSH प्रत्येक setting साठी त्याला आढळणारे पहिले value ठेवते. त्यामुळे सुरुवातीला समाविष्ट केलेली drop-in फाइल खालील कोणत्याही setting पेक्षा प्राधान्य घेते. तुमच्या settings अशा फाइलमध्ये हलवा जिचा मालक 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 उरली नाही, तर तो प्रॉम्प्ट महत्त्वाचा राहत नाही. कोणतेही उत्तर दिले तरी तुमच्या settings सुरक्षित राहतात, कारण त्या वेगळ्या फाइलमध्ये असतात.

Custom port साठी आणखी एक तपासणी आवश्यक आहे, कारण तो तुमच्या अपेक्षेच्या ठिकाणी नसेल:

systemctl is-enabled ssh.socket

यातून enabled दिसत असल्यास, listening port systemd च्या नियंत्रणाखाली आहे. त्यामुळे sshd_config मधील Port ओळ दुर्लक्षित केली जाते. Ubuntu ने 22.10 पासून sshd साठी socket activation वापरले आहे. म्हणून Port 2222 मध्ये केलेला बदल परिणाम करत नसल्यासारखा दिसतो. तो socket unit वर sudo systemctl edit ssh.socket वापरून सेट करा:

[Socket]
ListenStream=
ListenStream=2222

रिकामे ListenStream= आवश्यक आहे. ते inherited value काढून टाकते. ते नसल्यास socket 22 सोबत 2222 वरही listen करतो. sudo systemctl daemon-reload && sudo systemctl restart ssh.socket वापरून हा बदल लागू करा.

अपग्रेडनंतर, तुम्ही सध्या वापरत असलेले 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 करा, configuration दुरुस्त करा, sudo sshd -t चालवा आणि service restart करा. अपग्रेडच्या वेळी नव्हे, तर अपग्रेडपूर्वी 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 रोजी release झाले आणि 26.04.1 27 August 2026 रोजी scheduled आहे. तोपर्यंत 24.04 server ला कोणतेही नवीन release दिसत नाही. Prompt=normal वर switch करण्याऐवजी सध्याची setting तशीच ठेवा. Prompt=normal मुळे upgrade interim releases मधून होईल.

Upgrade पूर्ण करण्यासाठी server reboot करणे आवश्यक आहे का?

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

Upgrade in place करावे की नवीन 26.04 server तयार करावा?

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

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

सामान्य login shell मध्ये process ला SIGHUP मिळतो आणि ती मध्येच बंद होते. त्यामुळे dpkg अर्धवट configure राहते. प्रक्रिया tmux किंवा screen च्या आत सुरू करा. त्यामुळे ती सुरू राहते आणि पुन्हा connect करून पुढे चालू ठेवण्यासाठी tmux attach -t upgrade चालवता येते. Upgrader दुसरा प्रवेशमार्ग म्हणून port 1022 वर अतिरिक्त SSH daemon देखील सुरू करते. मात्र त्या port साठी firewall rule उघडत नाही. त्यामुळे आधी 1022 स्वतः allow करा आणि नंतर तो 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 नमूद करा, sudo nginx -t चालवा आणि त्यानंतर nginx reload करा. Apache वर mod_php वापरत असल्यास समतुल्य दुरुस्ती म्हणजे sudo a2dismod php8.3 चालवणे, त्यानंतर sudo a2enmod php8.5 चालवून restart करणे.