Ubuntu 24.04-ஐ 26.04-க்கு பாதுகாப்பாக upgrade செய்வது

Ubuntu 24.04-ஐ எப்போது 26.04-க்கு upgrade செய்யலாம்?

26.04.1 point release வெளியான பிறகு, ஒரு VPS-ல் Ubuntu 24.04-ஐ 26.04-க்கு upgrade செய்யலாம். இது 27 August 2026 அன்று திட்டமிடப்பட்டுள்ளது. அதுவரை, 24.04 server புதிய release-ஐக் கண்டறியாது; இது வேண்டுமென்றே செய்யப்படுகிறது. Ubuntu 26.04 LTS (Resolute Raccoon) 23 April 2026 அன்று வெளியிடப்பட்டது. ஆனால், Canonical நிறுவனம் முதல் point release-ன் போது மட்டுமே LTS-லிருந்து LTS-க்கு upgrade செய்யும் வசதியைத் திறக்கும். ஏனெனில், அந்த release-ல் தான் முதல் சில மாதங்களில் கண்டறியப்பட்ட நிறுவல் மற்றும் upgrade பிழைகள் சரிசெய்யப்படுகின்றன.

August 2026 தொடக்கத்தில் 24.04 box-ல் சரிபார்ப்பைச் செய்தால், உங்களுக்குக் கிடைப்பது இதுதான்:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

இது உங்கள் server-ல் உள்ள பிழை அல்ல. /etc/update-manager/release-upgrades-ல் Ubuntu Server-க்கான Prompt=lts உள்ளது. அதாவது, இந்த கருவி அடுத்த நீண்ட கால ஆதரவு (LTS) வெளியீட்டை மட்டுமே வழங்கும், அதுவும் அதன் .1 point release இருக்கும்போது மட்டுமே. Prompt=normal என்று அமைத்தால், அது 24.10, 25.04 மற்றும் 25.10 என ஒவ்வொன்றாக உங்களை அழைத்துச் செல்லும்; இவை இடைக்கால வெளியீடுகள் (interim releases) மற்றும் இவை அனைத்தும் காலாவதியாகிவிட்டன. அதை lts-லேயே விட்டுவிட்டு காத்திருக்கவும். Canonical-ன் அட்டவணையில் உள்ள தேதிகள் மாறக்கூடும், எனவே அந்த நாள் அமைதியாகக் கடந்துவிட்டால் மீண்டும் சரிபார்க்கவும்.

கீழே உள்ள ஒவ்வொரு கட்டளையையும் உங்கள் சொந்த server-ல், கொடுக்கப்பட்ட வரிசையில் நீங்களே இயக்க வேண்டும். நீங்கள் upgrade செய்யும் இயந்திரத்தில் release upgrade-ஐ ஒத்திகை பார்க்க முடியாது. இது kernel மற்றும் C library-ஐ மாற்றுகிறது, மேலும் முடிப்பதற்கு ஒரு reboot தேவைப்படுகிறது.

நீங்கள் மேம்படுத்த வேண்டுமா?

Ubuntu 24.04 ஆனது 2029 வரை நிலையான பாதுகாப்பு மேம்படுத்தல்களைப் பெறும், எனவே இயங்கிக்கொண்டிருக்கும் production server-க்கு எந்த காலக்கெடுவும் இல்லை. PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 அல்லது 7.0 kernel போன்ற 26.04-ல் உள்ள புதிய அம்சங்கள் தேவைப்பட்டால் மட்டும் மேம்படுத்தவும். வாடிக்கையாளர்களுக்குச் சேவை வழங்கும் ஒரு server-ஐ, வெறும் பதிப்பு எண் மாறியுள்ளது என்பதற்காக மட்டும் மாற்ற வேண்டிய அவசியமில்லை.

பின்வரும் சூழல்களில் in-place மேம்படுத்தலைத் தவிர்க்கவும்:

• உங்கள் provider-ன் console-ஐ (VNC அல்லது serial) பயன்படுத்தி நீங்கள் இதுவரை உள்நுழைந்ததில்லை என்றால். SSH செயலிழந்தால், அந்த console மட்டுமே server-ஐ மீண்டும் அணுக உதவும் ஒரே வழியாகும். நீங்கள் வெளியேற்றப்பட்ட பிறகு console வேலை செய்யவில்லை என்று கண்டறிவது மிகவும் தாமதமான செயலாகும்.
• ஒரு மணிநேர downtime-ஐ உங்களால் தாங்க முடியாது மற்றும் rollback வசதி இல்லை என்றால்.
• உங்கள் stack, resolute-க்கு இன்னும் வெளியிடப்படாத ஒரு third-party repository-ஐச் சார்ந்திருந்தால்.
• அந்த server இரண்டு ஆண்டுகளாகக் கையால் கட்டமைக்கப்பட்டு, அதில் என்னென்ன உள்ளது என்பது யாருக்கும் தெரியவில்லை என்றால்.

மாற்று வழி பெரும்பாலும் சிறந்தது: ஒரு புதிய 26.04 VPS-ஐ உருவாக்கி, உங்கள் stack-ஐ நிறுவி, தரவுகளை மீட்டெடுத்து, அது சரியாகச் செயல்பட்ட பிறகு DNS-ஐ மாற்றவும். புதிய server தன்னை நிரூபிக்கும் வரை பழைய server-ஐ இயங்க விடலாம்; இதில் rollback என்பது ஒரு DNS மாற்றமே தவிர, தரவு மீட்பு அல்ல. நீங்கள் இந்த வழியைத் தேர்ந்தெடுக்க விரும்பினால், புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதியிலிருந்து தொடங்கி, புதிய server-ஐச் சரியாகக் கட்டமைக்கவும்.

படி 1: மீட்டெடுக்கக்கூடிய வகையில் ஒரு backup எடுங்கள்

இரண்டு அடுக்குகளைப் பயன்படுத்துங்கள், ஏனெனில் அவை வெவ்வேறு வழிகளில் தோல்வியடையக்கூடும். ஒரு provider snapshot முழு வட்டுக்கும் (disk) பாதுகாப்பு அளிக்கிறது மற்றும் சில நிமிடங்களில் மீட்டெடுக்க முடியும். ஆனால், உங்கள் databases எழுதும்போதே இது எடுக்கப்படுவதால், இது application consistent-ஆக இருக்காது, மாறாக crash consistent-ஆக மட்டுமே இருக்கும். restic, server-க்கு வெளியே சேமிக்கப்படும் கோப்பு அளவிலான backup, தனிப்பட்ட கோப்புகளை மீட்டெடுக்கவும், உங்கள் கணக்கு முடக்கப்பட்டாலும் தரவுகளைப் பாதுகாக்கவும் உதவுகிறது.

முதலில் 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-க்கு மட்டுமே சீரான dump-ஐ வழங்குகிறது. MyISAM tables-க்கு database-ஐ நிறுத்த வேண்டியது அவசியம். /etc tarball-ஐத்தான் நீங்கள் உண்மையில் பயன்படுத்த வேண்டியிருக்கும், ஏனெனில் upgrade-ன் போது கேட்கப்படும் அனைத்து config கோப்புகளும் அதில் இருக்கும்.

நீங்கள் ஒருமுறை கூட மீட்டெடுக்காத backup என்பது வெறும் ஊகம் மட்டுமே. அவசர காலத்தில் தேவைப்படுவதற்கு முன்பே, இப்போதே அதிலிருந்து ஒரு கோப்பை எடுத்துச் சோதியுங்கள்.

படி 2: முதலில் 24.04-ஐ முழுமையாக patch செய்யவும்

do-release-upgrade சிதைந்த package நிலையைக் கொண்ட ஒரு system-ல் இயங்க மறுக்கும். முழுமையடையாத 24.04 patch, பிற்காலத்தில் ஏற்படும் பிழைகளைக் கண்டறிவதைக் கடினமாக்கும்.

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

dpkg --audit எதையும் அச்சிடவில்லை என்றால், எந்த package-ம் பாதியிலேயே configure செய்யப்படவில்லை என்று அர்த்தம். apt-mark showhold எதையும் அச்சிடவில்லை என்றால், upgrade-ஐத் தடுக்கும் வகையில் எந்த package-ம் ஒரு குறிப்பிட்ட version-ல் முடக்கப்படவில்லை (pinned) என்று அர்த்தம். அது பட்டியலிடும் எதையும் sudo apt-mark unhold மற்றும் package பெயரைப் பயன்படுத்தி விடுவிக்கவும், அல்லது அந்தத் தடுப்பு (hold) ஒரு காரணத்திற்காகவே உள்ளது என்பதை ஏற்றுக்கொண்டு இங்கேயே நிறுத்தவும்.

Kernel மாறியிருந்தால், கணினியை reboot செய்யவும். அப்போதுதான், இயங்கிக்கொண்டிருக்கும் code-க்கும் system கருதும் code-க்கும் இடையே முரண்பாடு இல்லாமல் upgrade செய்ய முடியும்.

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

பிறகு, disk இடத்தைச் சரிபார்க்கவும். Upgrader புதிய package தொகுப்பு முழுவதையும் பதிவிறக்கம் செய்த பின்னரே எதையும் நிறுவும். போதிய இடவசதி இல்லையெனில், எந்த filesystem-ல் இடம் பற்றாக்குறையாக உள்ளது என்பதைக் குறிப்பிட்டு அது நின்றுவிடும்.

df -h / /boot

/-ல் சுமார் 5 GB-க்கும் குறைவாக இடம் இருந்தால், சிக்கல் ஏற்படும். /boot 300 MB-க்கும் குறைவாக இருந்தால், kernel நிறுவலின் போது No space left on device பிழையுடன் அது தோல்வியடையும். பழைய kernel-களே இதற்கு முக்கிய காரணம், sudo apt --purge autoremove அவற்றை நீக்கி இடத்தைச் சுத்தம் செய்யும்.

தொடங்குவதற்கு முன் கவனிக்க வேண்டிய மற்றொரு விஷயம்: தானியங்கி பாதுகாப்பு மேம்படுத்தல்கள் (automatic security updates) இடையில் இயங்கினால், அவை 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 கணினியை செயலிழக்கச் செய்யக்கூடும். இது தனக்குத் தெரிந்த source-களைப் பிறகு மீண்டும் செயல்படுத்துகிறது, மற்றவற்றை comment செய்து விடுகிறது. கருவி உங்களுக்காக முடிவெடுக்கும் முன், நீங்கள் எதைச் சுமந்து கொண்டிருக்கிறீர்கள் என்பதை அறிந்து கொள்ளுங்கள்.

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-யில் இரண்டு வடிவங்களைப் பயன்படுத்துகிறது: பழைய ஒரு வரி .list கோப்புகள் மற்றும் Types:, Suites: புலங்களைக் கொண்ட deb822 .sources கோப்புகள். மேம்படுத்தலின் போது இவை இரண்டும் முடக்கப்படுகின்றன. ubuntu-security-status --thirdparty, எந்தவொரு Ubuntu காப்பகமும் வழங்காத, நீங்கள் கூடுதலாக இணைத்துள்ள நிறுவப்பட்ட package-களின் பட்டியலைக் காட்டுகிறது. /etc/apt/preferences.d/-ல் உள்ளவை அனைத்தும் pin-கள் ஆகும். noble-க்காக எழுதப்பட்ட ஒரு pin, புதிய release-லும் பழைய package-ஐயே தொடர்ந்து தேர்ந்தெடுக்கச் செய்யும்.

ஒவ்வொரு மூன்றாம் தரப்பு களஞ்சியத்திற்கும், நீங்கள் தொடங்குவதற்கு முன்பே விற்பனையாளர் புதிய codename-க்கான பதிப்பை வெளியிட்டுள்ளாரா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். Docker-ன் suites https://download.docker.com/linux/ubuntu/dists/-ல் பட்டியலிடப்பட்டுள்ளன, மற்ற விற்பனையாளர்களும் அதே directory-யைக் கொண்டுள்ளனர். இல்லாத ஒரு suite-ஐச் சுட்டிக்காட்டும் source, மேம்படுத்தலுக்குப் பிறகு முதல் apt update-ன் போது இதைக் காட்டும்:

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

விற்பனையாளர் வெளியிடும் வரை அந்த source-ஐ முடக்கப்பட்ட நிலையிலேயே வைத்திருங்கள். விற்பனையாளர் உருவாக்கிய codename-க்கு மாற்றுவது, தவறான system libraries-உடன் இணைக்கப்பட்ட package-களை நிறுவுவதற்கு வழிவகுக்கும்.

படி 4: சாதாரண SSH shell-க்கு பதிலாக tmux-ல் upgrade-ஐ இயக்கவும்

சாதாரண login shell-ல் do-release-upgrade இயங்கும்போது உங்கள் இணைப்பு துண்டிக்கப்பட்டால், அந்த process SIGHUP சிக்னலைப் பெற்று பாதியிலேயே நின்றுவிடும். இதனால் dpkg பாதியிலேயே configuration நிலையில் இருக்கும்; மீண்டும் இணைக்கத் தேவையான network stack கூட அந்த server-ல் வேலை செய்யாமல் போகலாம். எனவே, ஒரு terminal multiplexer-க்குள் இதை இயக்கவும். அப்போதுதான் உங்கள் client துண்டிக்கப்பட்டாலும் server-ல் அந்த process தொடர்ந்து இயங்கும்.

sudo apt install -y tmux
tmux new -s upgrade

அந்த session-க்குள்:

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

எந்த மாற்றத்தையும் செய்வதற்கு முன்பாக, upgrader போர்ட் 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.

அது அந்த போர்ட்டிற்காக உங்கள் firewall-ஐத் திறக்காது. ஏனெனில், அனுமதி கேட்காமல் firewall-ல் ஓட்டை போடுவது பாதுகாப்பற்றது. எனவே, தொடங்குவதற்கு முன்பே 1022 போர்ட்டை நீங்களே திறந்து வைத்துக்கொள்ளுங்கள். sudo ufw delete allow 1022/tcp முடிந்ததும் அதை மூடிவிடவும். உங்கள் service provider-ன் control panel-ல் server-க்கு வெளியே மற்றொரு firewall இருக்கலாம் என்பதையும் நினைவில் கொள்ளுங்கள்.

எப்படியாவது இணைப்பு துண்டிக்கப்பட்டால், மீண்டும் login செய்து tmux attach -t upgrade கட்டளையை இயக்கவும். நீங்கள் இல்லாதபோதும் upgrade தொடர்ந்து இயங்கிக்கொண்டிருந்திருக்கும்.

படி 5: configuration file கேட்கும் கேள்விகளுக்கு கவனமாக பதிலளிக்கவும்

நீங்கள் அல்லது ஏதேனும் ஒரு script மாற்றியமைத்த கோப்புகளுக்கு மட்டுமே dpkg கேள்விகளை எழுப்பும். எனவே, ஒவ்வொரு கேள்வியும் நீங்கள் வேண்டுமென்றே மாற்றியமைத்த ஒரு கோப்பைக் குறிக்கிறது. கேள்வியைத் தவிர்க்க 'Enter' அழுத்துவது, பாதுகாப்பான server-ஐ மீண்டும் இயல்புநிலை (default) நிலைக்குக் கொண்டு சென்றுவிடும்.

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-ஐப் பயன்படுத்தவும். இயல்புநிலையாகவே N தேர்ந்தெடுக்கப்பட்டிருக்கும்; இதுவே பாதுகாப்பான தேர்வாகும். ஏனெனில், உங்கள் கோப்பு தற்போது சரியாக இயங்குகிறது, ஆனால் புதிய தொகுப்பில் உள்ள கோப்பு இந்த machine-ல் இதுவரை இயங்கியதில்லை.

உங்கள் கோப்பைத் தக்கவைப்பதில் ஒரு சிறிய சிக்கல் உள்ளது: புதிய இயல்புநிலை அமைப்புகள் உங்களுக்குக் கிடைக்காது. server-ன் பணி சீரான பிறகு, அவசரமில்லாத நேரத்தில் அவற்றை ஒப்பிட்டுச் சரிசெய்து கொள்ளவும்.

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

பட்டியலிடப்படும் ஒவ்வொரு கோப்பும், உங்கள் கோப்பிற்கு அருகிலேயே சேமிக்கப்பட்டுள்ள maintainer-ன் பதிப்பாகும். அவற்றை ஒவ்வொன்றாக /etc/ssh/sshd_config மூலம் ஒப்பிட்டு, தேவையான அமைப்புகளை மட்டும் நகலெடுக்கவும். இரண்டு கோப்புகளைக் கையாள்வதில் கூடுதல் கவனம் தேவை: /etc/ssh/sshd_config, ஏனெனில் தவறான பதில் உங்கள் session-ஐ முடித்துவிடும்; மற்றொன்று உங்கள் web server configuration, ஏனெனில் தவறான பதில் தளங்களை முடக்கிவிடும்.

மேம்படுத்தலின் போது (upgrade), எந்தெந்த services-ஐ restart செய்ய வேண்டும் என்று needrestart கேட்கும். முழுப் பட்டியலையும் ஏற்கவும். வட்டில் (disk) இருந்து நீக்கப்பட்ட shared library கோப்பைப் பயன்படுத்தும் ஒரு daemon, பிற்காலத்தில் ஏதேனும் ஒரு கோரிக்கையின் போது திடீரென செயலிழக்கக்கூடும்; அது நீங்கள் கவனிக்காத நேரமாக இருக்கலாம்.

படி 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 கட்டளை பூஜ்ஜிய units-ஐப் பட்டியலிட வேண்டும்; அது எதையேனும் பட்டியலிட்டால், அதைச் சரிசெய்வதே உங்கள் அடுத்த பணி. இறுதி கட்டளையான apt update, release images உருவாக்கப்பட்ட பிறகு வெளியிடப்பட்ட அனைத்து updates-களையும் பதிவிறக்கம் செய்யும்.

PostgreSQL 16 முதல் 18 வரை: அமைதியாகப் பின்தங்கியிருக்கும் cluster

Ubuntu 24.04-ல் PostgreSQL 16-ம், 26.04-ல் PostgreSQL 18-ம் வருகின்றன. இந்த upgrade, 16-க்கு அருகிலேயே 18-ஐ நிறுவும், உங்கள் தரவுகளை அது நகர்த்தாது. Debian-ன் postgresql-common அடுக்கு, புதிய major version-க்காக அடுத்த காலியாக உள்ள port-ல் ஒரு புதிய cluster-ஐ உருவாக்கும். எனவே, 16 உங்கள் தரவுகளுடன் port 5432-ல் தொடர்ந்து இயங்கும், 18 காலியாக port 5433-ல் அமரும். உங்கள் 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

முதலில் காலியாக உள்ள 18 cluster-ஐ நீக்கிவிடவும், ஏனெனில் pg_upgradecluster ஏற்கனவே இருக்கும் target cluster-ல் எழுதாது. இயல்பான முறையில் 16-ல் உள்ள தரவுகள் dump செய்யப்பட்டு 18-ல் ஏற்றப்படும், எனவே database-ன் அளவிற்கு இணையான disk space உங்களுக்குத் தேவைப்படும். -m upgrade இதற்குப் பதிலாக pg_upgrade-ஐப் பயன்படுத்துகிறது, இது பெரிய database-களுக்கு மிக வேகமாக இருக்கும். அது முடிந்ததும், Port column-ஐப் பார்க்கவும்: புதிய cluster 5432-ஐ எடுத்துக்கொள்ளும், பழையது நிறுத்தப்பட்ட நிலையில் இருக்கும். analyze pass-ஐ நீங்களே இயக்கவும், ஏனெனில் புதிதாக ஏற்றப்பட்ட cluster-ல் புள்ளிவிவரங்கள் (statistics) இருக்காது, முதல் சில queries மெதுவாக இருக்கும்.

புதிய cluster-ல் சில நாட்களுக்கு application-ஐச் சோதித்துப் பார்க்கவும். அதன் பிறகு பழையதை நீக்கவும்:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

பழைய cluster-ன் data directory-யே நீங்கள் வைத்திருக்கும் மிக வேகமான rollback வசதியாகும். upgrade செய்த அன்றே அதை நீக்கிவிடாதீர்கள்.

MySQL 8.0 முதல் 8.4 வரை: சர்வரை நிறுத்தும் நீக்கப்பட்ட விருப்பம்

26.04 பதிப்பில் MySQL 8.0-லிருந்து 8.4 LTS-க்கு மாறுகிறது. இதில் இரண்டு மாற்றங்கள் சர்வர்களில் சிக்கலை ஏற்படுத்துகின்றன.

முதலில், புதிய பதிப்பில் நீக்கப்பட்ட ஒரு விருப்பம் (option) configuration கோப்பில் இருந்தால், mysqld தொடங்க மறுக்கும். default_authentication_plugin என்பது பொதுவாகப் பயன்படுத்தப்படும் ஒன்று, ஏனெனில் பல பழைய வழிகாட்டிகள் இதை அமைக்கச் சொல்கின்றன. இதனால் service தோல்வியடையும், மேலும் journalctl -u mysql -n 50 அந்தத் தெரியாத மாறியை (variable) நேரடியாகக் குறிப்பிடும். /etc/mysql/mysql.conf.d/-ல் உள்ள கோப்பிலிருந்து அந்த வரியை நீக்கிவிட்டு, பின் sudo systemctl start mysql செய்யவும்.

இரண்டாவதாக, 8.4-ல் mysql_native_password plugin இயல்பாகவே (default) இயக்கப்படுவதில்லை. எனவே, அதைப் பயன்படுத்தும் கணக்குகள் எதிலும் உள்நுழைய முடியாது. நீங்கள் இன்னும் 8.0-ல் இருக்கும்போதே இதைச் சரிபார்க்கவும்:

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

மேம்படுத்தலுக்கு (upgrade) முன்பே mysql_native_password என்று காட்டும் அனைத்து கணக்குகளையும் மாற்றவும், பின்னர் உங்கள் application configuration-ல் கடவுச்சொல்லைப் புதுப்பிக்கவும்:

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-ஐ மீண்டும் இயக்கலாம். இது ஒரு தற்காலிக ஏற்பாடு மட்டுமே, ஏனெனில் இந்த plugin முற்றிலும் நீக்கப்பட உள்ளது.

PHP 8.3 முதல் 8.5 வரை: உங்கள் vhosts குறிப்பிடும் socket நீக்கப்பட்டுவிட்டது

24.04 பதிப்பு PHP 8.3-ஐயும், 26.04 பதிப்பு PHP 8.5-ஐயும் வழங்குகிறது. இந்த packages பதிப்பு சார்ந்த பாதைகளில் (versioned paths) நிறுவப்படுகின்றன, உங்கள் web server configuration-ஐ எவையும் தானாக மாற்றாது. fastcgi_pass unix:/run/php/php8.3-fpm.sock;-ஐக் கொண்ட ஒரு nginx vhost, தற்போது எந்த process-உம் உருவாக்காத ஒரு socket-ஐக் குறிப்பிடுகிறது. இதனால் ஒவ்வொரு PHP கோரிக்கையும் 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

Apache-ல் mod_php பயன்படுத்தினால் அறிகுறி வேறாக இருக்கும்: Apache தொடங்காது, மேலும் sudo apache2ctl -t, libphp8.3.so கோப்பு இல்லாததால் அதை ஏற்ற முடியவில்லை என்று தெரிவிக்கும். enable செய்யப்பட்ட module, நீக்கப்பட்ட ஒரு package-க்கான symlink ஆக இருக்கும்.

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

நீங்கள் Ubuntu 24.04-ல் LAMP stack மூலம் இந்த server-ஐ உருவாக்கியிருந்தால், அந்த இரண்டு பாதைகளையும் சரிபார்க்க வேண்டும். ஏனெனில் அந்த வழிகாட்டி உங்களை ஒரு பதிப்பு சார்ந்த module பெயர் மற்றும் பதிப்பு சார்ந்த socket-உடன் விட்டுவிடும்.

உங்கள் php.ini மாற்றங்களும் தானாக மாறாது. memory_limit, upload_max_filesize மற்றும் நீங்கள் அமைத்த பிற மாற்றங்கள் /etc/php/8.3/-ல் உள்ளன, புதிய பதிப்பு default அமைப்புகளுடன் தொடங்குகிறது. இரண்டு கோப்புகளையும் diff செய்து, மதிப்புகளைக் கையால் நகலெடுக்கவும். பழைய கோப்பை அப்படியே புதிய கோப்பின் மேல் நகலெடுத்தால், 8.3-ன் default அமைப்புகள் 8.5 நிறுவலில் சிக்கலை ஏற்படுத்தும். பிறகு php -m-ஐ இயக்கி ஒப்பிடவும்: php8.3-redis என நிறுவப்பட்ட extension-க்கு அதன் php8.5- package தேவை. அது ஒரு PPA-விலிருந்து வந்திருந்தால், மேம்படுத்தல் (upgrader) அந்த source-ஐ முடக்கியிருக்கும், எனவே அந்த extension விடுபட்டிருக்கும்.

Certificates-ஐத் தனியாக ஒருமுறை சரிபார்க்க வேண்டும். மேம்படுத்தலுக்குப் பிறகு sudo certbot renew --dry-run-ஐ இயக்கவும். இது live certificate-ஐப் பாதிக்காமல், web server reload hook உட்பட முழு புதுப்பித்தல் பாதையையும் (renewal path) சோதிக்கும். மாறிய ஒரு service பெயர் அல்லது binary-ஐ அழைக்கும் hook, 60 நாட்களுக்குப் பிறகு அமைதியாகத் தோல்வியடைவதற்குப் பதிலாக, இப்போதே உங்கள் கண்முன்னே தோல்வியடையும். nginx-ல் Let's Encrypt உடன் Certbot அந்த hooks எப்படி இருக்க வேண்டும் என்பதை விளக்குகிறது.

SSH: நீங்கள் பணிபுரியும் அமர்வை முடிவுக்குக் கொண்டுவரும் தோல்வி

sshd_config prompt என்பது பயனர்கள் தங்களைத் தாங்களே வெளியேற்றிக்கொள்ளும் இடமாகும். Y என்று பதிலளிப்பது, பராமரிப்பாளரின் கோப்பை நிறுவுகிறது; இது உங்கள் PermitRootLogin, PasswordAuthentication, AllowUsers, Port மற்றும் நீங்கள் சேர்த்த மற்ற அனைத்து வரிகளையும் நீக்கிவிடும். உங்கள் firewall ஒரு குறிப்பிட்ட custom port-ஐ மட்டுமே அனுமதித்து, தொகுக்கப்பட்ட configuration 22-ல் இயங்கினால், அடுத்த இணைப்பு மறுக்கப்படும். நீங்கள் தற்போது அமர்ந்திருக்கும் அமர்வே உங்களின் கடைசி அமர்வாகிவிடும்.

Upgrade செய்வதற்கு முன்பே இதைத் தடுக்கவும். 24.04-ல் உள்ள /etc/ssh/sshd_config, Include /etc/ssh/sshd_config.d/*.conf உடன் தொடங்குகிறது. OpenSSH ஒவ்வொரு அமைப்பிற்கும் முதலில் வாசிக்கும் மதிப்பையே எடுத்துக்கொள்ளும் என்பதால், மேலே சேர்க்கப்படும் drop-in கோப்பு கீழே உள்ள எதையும் விட முன்னுரிமை பெறும். உங்கள் அமைப்புகளை 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 ஒரு பொருட்டல்ல: எந்தப் பதிலைத் தேர்ந்தெடுத்தாலும் உங்கள் அமைப்புகள் மாறாது, ஏனெனில் அவை வேறு கோப்பில் உள்ளன.

Custom port-க்கு ஒரு கூடுதல் சரிபார்ப்பு தேவை, ஏனெனில் அது நீங்கள் நினைக்கும் இடத்தில் இல்லாமல் இருக்கலாம்:

systemctl is-enabled ssh.socket

இது enabled என்று காட்டினால், systemd அந்த listening port-ஐக் கட்டுப்படுத்துகிறது மற்றும் sshd_config-ல் உள்ள Port வரி புறக்கணிக்கப்படும். Ubuntu 22.10 முதல் sshd-க்கு socket activation-ஐப் பயன்படுத்துகிறது; இதனால்தான் Port 2222-ல் செய்யப்படும் மாற்றம் எதையும் செய்யாதது போலத் தோன்றும். அதற்குப் பதிலாக, sudo systemctl edit ssh.socket மூலம் socket unit-ல் அதை அமைக்கவும்:

[Socket]
ListenStream=
ListenStream=2222

வெற்று ListenStream= அவசியம். இது பெறப்பட்ட மதிப்பை நீக்குகிறது; இது இல்லையென்றால், socket 22 மற்றும் 2222 ஆகிய இரண்டிலும் listen செய்யும். sudo systemctl daemon-reload && sudo systemctl restart ssh.socket மூலம் இதைச் செயல்படுத்தவும்.

Upgrade செய்த பிறகு, நீங்கள் இருக்கும் அமர்வை மூடுவதற்கு முன்:

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

பிறகு உங்கள் கணினியில் இரண்டாவது terminal-ஐத் திறந்து மீண்டும் login செய்யவும். அந்த இரண்டாவது terminal-ல் கிடைக்கும் working shell மட்டுமே உண்மையான சான்று. அது கிடைக்கும் வரை முதல் அமர்வை மூடாதீர்கள். Hardening SSH on a VPS அந்த drop-in கோப்பில் வைத்திருக்க வேண்டிய பயனுள்ள அமைப்புகளை விளக்குகிறது.

ஏற்கனவே தாமதமாகிவிட்டால், உங்கள் provider வழங்கும் web console மூலம் SSH-ஐப் பயன்படுத்தாமல் login செய்யலாம். அங்கு login செய்து, configuration-ஐச் சரிசெய்து, sudo sshd -t-ஐ இயக்கி, service-ஐ restart செய்யவும். Upgrade-க்கு இடையில் அல்லாமல், அதற்கு முன்பே console access-ஐச் சோதித்துப் பார்க்க வேண்டியதன் அவசியத்தை இந்தக் console உணர்த்துகிறது.

FAQ

Ubuntu 24.04-ல் "No new release found" என்று do-release-upgrade ஏன் காட்டுகிறது?

ஏனெனில் Ubuntu Server-ல் /etc/update-manager/release-upgrades கோப்பில் Prompt=lts என்ற அமைப்பு உள்ளது. இந்த அமைப்பு, அடுத்த நீண்ட கால ஆதரவு (LTS) பதிப்பின் முதல் point release வெளியான பிறகு மட்டுமே அதை வழங்குகிறது. Ubuntu 26.04 LTS பதிப்பு 23 April 2026 அன்று வெளியானது, அதன் 26.04.1 பதிப்பு 27 August 2026 அன்று வெளியாகத் திட்டமிடப்பட்டுள்ளது. அந்த நாள் வரை, 24.04 server புதிய பதிப்பைக் கண்டறியாது. Prompt=normal-க்கு மாற்றுவதற்குப் பதிலாக, இந்த அமைப்பை அப்படியே விடுவது சிறந்தது; இல்லையெனில் அது உங்களை இடைக்கால (interim) பதிப்புகள் வழியாக அழைத்துச் செல்லும்.

மேம்படுத்தலை முடிக்க server-ஐ reboot செய்ய வேண்டுமா?

ஆம். இந்த மேம்படுத்தல் புதிய kernel, புதிய C library மற்றும் புதிய init system ஆகியவற்றை நிறுவுகிறது. நீங்கள் restart செய்யும் வரை, இயங்கும் system பழையவற்றையே பயன்படுத்தும். do-release-upgrade இறுதியில் reboot செய்யக் கேட்கும். "பிறகு" செய்யலாம் என்று விட்டுவிட்டால், அந்த machine இரண்டு பதிப்புகளின் கலவையில் இயங்கும். மீண்டும் தொடங்கிய பிறகு, புதிய kernel-ஐச் சரிபார்க்க uname -r-ஐயும், சரியாக இயங்காத services-ஐக் கண்டறிய systemctl --failed-ஐயும் பயன்படுத்தவும்.

நான் in-place மேம்படுத்தல் செய்ய வேண்டுமா அல்லது புதிய 26.04 server-ஐ உருவாக்க வேண்டுமா?

முடிந்தவரை புதிய server-ஐ உருவாக்குங்கள். புதிய VPS-ல் stack-ஐ நிறுவி, தரவுகளை மீட்டு, பழைய server traffic-ஐக் கையாண்டுகொண்டிருக்கும்போதே அனைத்தையும் சோதிக்கலாம். இதனால் ஏதேனும் சிக்கல் ஏற்பட்டால், backup-லிருந்து மீட்காமல் DNS மாற்றத்தின் மூலம் எளிதாக rollback செய்யலாம். server-ல் உள்ள தரவுகளை நகர்த்துவது கடினமாக இருந்தாலோ, provider ஒவ்வொரு machine-க்கும் கட்டணம் வசூலித்தாலோ, அல்லது உங்களிடம் snapshot மற்றும் console access இருந்தாலோ மட்டும் in-place மேம்படுத்தலைத் தேர்ந்தெடுக்கவும். in-place மேம்படுத்தல் முறை பரவலாகப் பயன்படுத்தப்பட்டாலும், அது நடக்கும் ஒரு மணி நேரத்தில் அதைத் தவிர்க்க முடியாது.

மேம்படுத்தலின் போது SSH இணைப்பு துண்டிக்கப்பட்டால் என்னவாகும்?

சாதாரண login shell-ல் மேம்படுத்தல் நடக்கும்போது, process SIGHUP சிக்னலைப் பெற்று பாதியிலேயே நின்றுவிடும்; இது dpkg-ஐ அரைகுறையாக விட்டுவிடும். எனவே, tmux அல்லது screen-க்குள் மேம்படுத்தலைத் தொடங்கவும்; அப்போதுதான் இணைப்பு துண்டிக்கப்பட்டாலும் process தொடர்ந்து இயங்கும். நீங்கள் மீண்டும் இணைந்து tmux attach -t upgrade கட்டளையை இயக்கி மேம்படுத்தலைத் தொடரலாம். மேம்படுத்தல் கருவி port 1022-ல் ஒரு கூடுதல் SSH daemon-ஐயும் தொடங்கும். ஆனால் அது firewall-ஐத் தானாகத் திறக்காது, எனவே நீங்களே port 1022-ஐத் திறந்து, வேலை முடிந்ததும் மூடிவிடவும்.

மேம்படுத்தலுக்குப் பிறகு எனது PHP தளம் 502 பிழையைக் காட்டுகிறது. என்ன சிக்கல்?

பதிப்பு மாறியதால் PHP FPM socket பாதை மாறியுள்ளது. Ubuntu 24.04-ல் PHP 8.3 இயங்குகிறது, 26.04-ல் PHP 8.5 இயங்குகிறது. எனவே, உங்கள் nginx vhost-ல் குறிப்பிடப்பட்டுள்ள /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 செய்யவும்.