VPS-ல் reboot செய்யாமல் kernel patch செய்வது எப்படி?

VPS-ல் live kernel patching எவ்வாறு செயல்படுகிறது

Live kernel patching என்பது இயங்கிக்கொண்டிருக்கும் ஒரு machine-ல், reboot செய்யாமலும், network connections துண்டிக்கப்படாமலும் kernel security திருத்தங்களைச் செயல்படுத்துவதாகும். ஒரு function-ன் திருத்தப்பட்ட நகல் kernel module-ஆக ஏற்றப்படும்; பழைய function-க்கு வரும் ஒவ்வொரு அழைப்பும் புதிய நகலுக்குத் திருப்பி விடப்படும். இந்தச் செயல்பாட்டின் போது server தொடர்ந்து traffic-ஐக் கையாளும். இந்த ஒரு நுட்பமே live patching எதற்குப் பயனுள்ளது, எதைச் செய்ய முடியாது என்பதை விளக்குகிறது.

இது நேரத்தை மட்டுமே பெற்றுத் தருகிறது. இது reboot செய்வதற்கான தேவையை நீக்காது. ஆறு மாதங்களாக live patching செய்யப்பட்ட ஒரு server, இன்னும் வட்டில் (disk) உள்ள பழைய kernel image-லேயே இயங்கிக்கொண்டிருக்கும். அந்தப் patches அனைத்தும் memory-ல் மட்டுமே இருக்கும்.

Live patching பெரும்பாலும் managed plan-ன் ஒரு அம்சமாக விற்கப்படுகிறது. Unmanaged server-ல், இரண்டு கட்டளைகள் (commands) மூலம் நீங்களே இதைச் செயல்படுத்தலாம். managed மற்றும் unmanaged VPS ஆகியவற்றுக்கு இடையேயான கட்டண வித்தியாசத்தைச் செலுத்தும் முன், இதைப் புரிந்துகொள்வது அவசியம்.

Live kernel patching எவ்வாறு செயல்படுகிறது?

Kernel-ல் உள்ளமைக்கப்பட்ட (built-in) live patching core உள்ளது, இது CONFIG_LIVEPATCH மூலம் compile செய்யப்படுகிறது. உங்கள் இயங்கும் kernel-ல் இது உள்ளதா எனச் சரிபார்க்கவும்:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

CONFIG_LIVEPATCH=y என்று ஒரு வரி இருந்தால், நீங்கள் இயக்கும் kernel-ல் அந்த core உள்ளது என்று அர்த்தம். அது இல்லையென்றால், அந்த machine-ல் எந்த live patching சேவையும் செயல்படாது.

இந்த redirection செயல்முறைக்கு kernel-ன் function tracer ஆன ftrace பயன்படுத்தப்படுகிறது. பெரும்பாலான kernel functions-ன் தொடக்கத்தில், arguments அல்லது stack-ஐ அணுகுவதற்கு முன்பே, ஒரு call instruction இருக்கும்படி compile செய்யப்படுகின்றன. Ftrace அந்த call site-ஐ ஒரு hook-ஆகப் பயன்படுத்துகிறது. ஒரு patch-ஐப் பயன்படுத்தும்போது, live patching core அந்த target function-ல் ஒரு ftrace handler-ஐப் பதிவு செய்கிறது. அந்த handler, execution-ஐ மாற்று function-க்கு (replacement function) திருப்பிவிடும். Kernel ஆவணங்கள் இதைத் தெளிவாகக் கூறுகின்றன: "Livepatching பொதுவாக function parameters அல்லது stack மாற்றப்படுவதற்கு முன்பே, function entry-ன் தொடக்கத்திலேயே குறியீட்டை (code) திருப்பிவிட வேண்டும்."

இந்த வாக்கியத்திலிருந்து இரண்டு விளைவுகள் ஏற்படுகின்றன, இவை பின்னாளில் முக்கியமானவை. Ftrace மூலம் hook செய்யக்கூடிய function-களை மட்டுமே patch செய்ய முடியும்; எனவே, அந்த entry call இல்லாமல் compile செய்யப்பட்ட function-களைப் patch செய்ய முடியாது. மேலும், patching-ன் அலகு ஒரு முழு function ஆகும்; ஒரு function-க்குள் இருக்கும் ஒற்றை வரியை மட்டும் patch செய்ய முடியாது.

இயங்கும் system-ஐப் பாதுகாப்பாக மாற்றுவதுதான் கடினமான பகுதி. நீங்கள் function-ஐ மாற்றும்போது, பழைய குறியீடு ஏதேனும் ஒரு CPU stack-ல் இயங்கிக்கொண்டிருந்தால், பழைய மற்றும் புதிய செயல்பாடுகள் கலந்துவிடும். Upstream Linux இதை per-task consistency model மூலம் கையாளுகிறது. இது kernel ஆவணங்களில் ஒரு hybrid முறையாக விவரிக்கப்பட்டுள்ளது: "இது kGraft-ன் per-task consistency மற்றும் syscall barrier switching ஆகியவற்றை, kpatch-ன் stack trace switching-உடன் இணைக்கிறது." ஒரு task தற்போது patch செய்யப்பட்ட function-க்குள் இல்லை என்பதை kernel உறுதிப்படுத்திய பிறகு, அந்த task புதிய குறியீட்டிற்கு மாற்றப்படும். அனைத்து task-களும் மாறும் வரை, அந்த patch transition நிலையில் இருக்கும்.

இதன் முடிவை நீங்களே பார்க்கலாம். பயன்படுத்தப்பட்ட patches /sys/kernel/livepatch-ன் கீழ் தோன்றும். ஒவ்வொரு patch-க்கும் ஒரு directory இருக்கும், அதற்குள் patch செய்யப்பட்ட functions பட்டியலிடப்பட்டிருக்கும்.

ls /sys/kernel/livepatch/

பட்டியல் காலியாக இருந்தால், நினைவகத்தில் (memory) எந்த live patch-உம் ஏற்றப்படவில்லை என்று அர்த்தம். புதிய server-ல் இதுவே இயல்பான தொடக்க நிலை ஆகும்.

Live kernel patching எவற்றையெல்லாம் சரிசெய்ய முடியாது

Function-களின் உடற்பகுதிகள் (bodies) மட்டுமே patch செய்யப்படுகின்றன. மற்றவை எவையும் மாற்றப்படுவதில்லை.

• மாற்றப்பட்ட தரவு அமைப்புகள் (Data structures). ஒரு upstream fix, ஒரு struct-ல் புதிய field-ஐச் சேர்த்தாலோ அல்லது ஏற்கனவே உள்ள field-ன் அர்த்தத்தை மாற்றினாலோ, ஏற்கனவே ஒதுக்கப்பட்டு பயன்பாட்டில் உள்ள object-களைப் பாதுகாப்பாக மாற்றுவதற்கு வழி இல்லை. kpatch திட்டம் இது குறித்து நேரடியாகக் கூறுகிறது: "Statically ஒதுக்கீடு செய்யப்பட்ட தரவுகளை மாற்றும் patches நேரடியாக ஆதரிக்கப்படுவதில்லை." Shadow variables மற்றும் callbacks இதற்கு ஒரு தீர்வாக இருந்தாலும், அவை தானியங்கி முறையில் அல்லாமல், ஒவ்வொரு patch-க்கும் கைமுறையாக எழுதப்பட வேண்டும்.
• ஒரே நேரத்தில் பல function-களில் பரவியிருக்கும் திருத்தங்கள். ஒரு குழுவாக உள்ள பல function-களில் lock ordering-ஐ மாற்றும் ஒரு திருத்தத்திற்கு, அவை அனைத்தும் ஒரே நேரத்தில் மாற வேண்டும். ஆனால், consistency model முழு கணினியையும் ஒரே நொடியில் முடக்குவதற்குப் பதிலாக, பணிகளை (tasks) மாற்றியே செயல்படுகிறது.
• தொடக்கக் குறியீடு (Initialisation code). __init எனக் குறிக்கப்பட்ட function-கள், உங்கள் server தொடங்கும்போதே இயங்கி, நினைவகத்திலிருந்து விடுவிக்கப்பட்டிருக்கும். எனவே, அவற்றை redirect செய்வதற்கு அங்கு எதுவும் இருக்காது.
• புதிய kernel பதிப்புகள் மற்றும் புதிய அம்சங்கள். Live patching என்பது ஒரே kernel தொடருக்குள் ஒரு patch நிலையிலிருந்து அடுத்த நிலைக்கு உங்களை நகர்த்தும். இது ஒரு தொடரிலிருந்து அடுத்த தொடருக்கு உங்களை மாற்றாது, புதிய அம்சங்களையும் சேர்க்காது. உங்களுக்குப் புதிய தொடரில் உள்ள ஏதேனும் தேவைப்பட்டால், உதாரணமாக Linux 7.1-ல் கொண்டுவரப்பட்ட மாற்றங்கள், நீங்கள் அந்த kernel-ஐ நிறுவி, reboot செய்ய வேண்டும்.
• Userspace. Canonical இதற்கான எல்லையைத் தெளிவாகக் கூறுகிறது: "Canonical Livepatch, OpenSSL அல்லது glibc போன்ற userspace libraries-ஐப் patch செய்வதில்லை. ஏனெனில், அது unattended-upgrades அல்லது ஒரு systems management tool-ன் பொறுப்பாகும்." Live patched kernel-ஐ மட்டும் வைத்துக்கொண்டு, பழைய OpenSSL-ஐ வைத்திருப்பது முழுமையான பாதுகாப்பு அல்ல. எனவே, அதே server-ல் unattended upgrades மூலம் userspace packages-ஐக் கையாளுவதை உறுதிப்படுத்தவும்.

Ubuntu-வின் சேவையில் தீவிரத்தன்மை (severity) குறித்த எல்லையும் உள்ளது. Canonical நிறுவனம், "Critical மற்றும் High Common Vulnerability Scoring System (CVSS) மற்றும் Ubuntu Priority மதிப்பீடுகளைக் கொண்ட kernel பாதிப்புகளை மட்டுமே patch செய்கிறது" என்று கூறுகிறது. ஒரு CVE (common vulnerabilities and exposures) அடையாளங்காட்டி ஒரு குறைபாட்டைக் குறிக்கிறது, CVSS என்பது அதனுடன் இணைக்கப்பட்ட மதிப்பெண் ஆகும். Medium-rated kernel CVE-கள் வட்டில் உள்ள package-ல் மட்டுமே சரிசெய்யப்படும், live patch செய்யப்படாது. எனவே, அவை அடுத்த reboot-க்குப்பிறகே உங்கள் இயங்கும் kernel-ஐ வந்தடையும்.

நேரடி kernel patching-க்கான விருப்பங்கள் யாவை?

பொதுவாகப் பயன்பாட்டில் மூன்று வழிமுறைகள் உள்ளன, இவை அனைத்தும் ஒரே kernel கட்டமைப்பையே இயக்குகின்றன.

Canonical Livepatch என்பது Ubuntu Pro மூலம் வழங்கப்படுகிறது. தனிப்பட்ட பயன்பாட்டிற்கு Ubuntu Pro இலவசமானது. Canonical-ன் கூற்றுப்படி, "இது தனிப்பட்ட பயன்பாட்டிற்கு 5 physical machines வரை எப்போதும் இலவசமாகவே இருக்கும்", மேலும் அதிகாரப்பூர்வ Ubuntu Community உறுப்பினர்களுக்கு இது 50 machines வரை உயரும். ஆகஸ்ட் 2026 நிலவரப்படி இதுவே ஆவணப்படுத்தப்பட்ட வரம்பாகும். வணிக ரீதியான பயன்பாட்டிற்கு கட்டணச் சந்தா தேவை. ஆதரிக்கப்படும் long term support (LTS) வெளியீடுகளின் general availability (GA) kernels மற்றும் அவற்றின் hardware enablement (HWE) kernels ஆகியவற்றுக்கு, generic, aws, azure, gcp, oracle, ibm மற்றும் lowlatency போன்ற பல்வேறு வகைகளில் இந்த சேவை வழங்கப்படுகிறது. நீங்கள் ஒரு தீர்வைச் சார்ந்திருப்பதற்கு முன், உங்கள் kernel-ஐ Canonical வெளியிட்ட kernel பட்டியலுடன் சரிபார்க்கவும்.

TuxCare வழங்கும் KernelCare என்பது ஒரு வணிக ரீதியான agent ஆகும். இது முதல் தரப்பு சேவை இல்லாத distributions உட்பட பலவற்றில் இயங்குகிறது. இதன் ஆவணப்படுத்தப்பட்ட நிறுவல் ஒரு vendor script மூலம் நடைபெறுகிறது, curl -s -L https://kernelcare.com/installer | bash, அதைத் தொடர்ந்து key-based உரிமத்திற்காக /usr/bin/kcarectl --register KEY பயன்படுத்தப்படுகிறது. இந்த agent புதிய patches-ஐ அதன் சொந்த கால அட்டவணையில் சரிபார்க்கிறது, மேலும் /usr/bin/kcarectl --update கட்டளை ஒரு சோதனையை கட்டாயப்படுத்துகிறது. நீங்கள் முக்கியமாகக் கருதும் server-ல் ஒரு script-ஐ shell-க்கு pipe செய்வதற்கு முன், அந்த installer-ஐப் படித்துப் பார்க்கவும்.

kpatch மற்றும் kGraft ஆகியவை முன்னோடித் தொழில்நுட்பங்கள். kGraft SUSE நிறுவனத்திடமிருந்தும், kpatch Red Hat நிறுவனத்திடமிருந்தும் வந்தவை. இன்றைய upstream Linux-ல் உள்ள நேரடி patching மையம் இந்த இரண்டு கருத்துகளின் இணைப்பாகும். kpatch தற்போது முடிவுக்கு வருகிறது: அதன் README-ல் Linux 6.19 முதல் "kpatch திட்டம் கைவிடப்பட்டு பராமரிப்பு முறையில் உள்ளது" என்று குறிப்பிடப்பட்டுள்ளது, மேலும் upstream kernel-ல் kpatch-build-க்கு பதிலாக klp-build பயன்படுத்தப்படுகிறது. RHEL மற்றும் அதன் rebuilds-ல், patches-ஐ நீங்களே உருவாக்குவதற்குப் பதிலாக, அந்த distribution வழங்கும் சொந்தச் சேவையையே பயன்படுத்த வேண்டும்.

உங்கள் distribution எதை ஆதரிக்கிறது மற்றும் உங்கள் உரிமம் எதை அனுமதிக்கிறது என்பதைப் பொறுத்து தேர்வு செய்யவும். ஒவ்வொரு வழக்கிலும் kernel-நிலை முடிவு ஒன்றாகவே இருக்கும்.

Ubuntu-வில் Canonical Livepatch-ஐ செயல்படுத்துவது எப்படி

முதலில் உங்கள் Ubuntu Pro கணக்கு பக்கத்திலிருந்து ஒரு token-ஐப் பெறவும். கீழே உள்ள இரண்டு கட்டளைகளுக்கும் வெளிச்செல்லும் network இணைப்பு அவசியம், ஏனெனில் client, Canonical-ன் server-களுடன் இணைந்து patches-ஐப் பெறுகிறது.

sudo pro attach TOKEN
sudo pro status

Token இல்லாமல் sudo pro attach கட்டளையை இயக்கினால், அது browser வழியாகச் செயல்படும் முறையைத் தொடங்கி, Canonical தளத்தில் உள்ளிட வேண்டிய ஒரு code-ஐக் காண்பிக்கும். இணைக்கும்போது (attaching), பரிந்துரைக்கப்பட்ட சேவைகள் தானாகவே செயல்படுத்தப்படும்; தற்போதைய LTS release-ல் Livepatch-ம் இதில் அடங்கும். நீங்கள் சேவைகளைத் தேர்வு செய்ய விரும்பினால் sudo pro attach --no-auto-enable-ஐப் பயன்படுத்தவும்.

Livepatch ஏற்கனவே செயல்பாட்டில் இல்லை என்றால்:

sudo pro enable livepatch
sudo canonical-livepatch status

இந்தச் சேவை canonical-livepatch snap மூலம் இயங்குகிறது, எனவே இந்தச் செயல்பாட்டை முடிக்க snapd சரியாக இயங்க வேண்டும். pro status கட்டளை, சேவைகளின் தகுதி மற்றும் நிலையை ஒரு அட்டவணையாகக் காண்பிக்கும். canonical-livepatch status கட்டளை kernel வாரியான விவரங்களைக் காண்பிக்கும், Canonical-ன் ஆவணங்கள் இந்த வடிவிலான வெளியீட்டைக் காட்டுகின்றன:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

இரண்டு வரிகள் இதற்கான பதிலைக் கொண்டுள்ளன. kernel state, நீங்கள் இயக்கும் series இந்தச் சேவையின் கீழ் வருகிறதா என்பதைக் குறிக்கும்; Livepatch ஆதரிக்காத kernel-ஐ நீங்கள் boot செய்யும்போது இந்த வரி பிழையாக மாறும். patch state, அந்த kernel-க்குத் தேவையான patches ஏற்றப்பட்டுள்ளதா என்பதைக் குறிக்கும். patches ஏற்றப்படாத, ஆனால் சேவையின் கீழ் வரும் kernel என்பது client சார்ந்த சிக்கல். சேவையின் கீழ் வராத kernel என்பது kernel சார்ந்த சிக்கல், இதை எந்த client அமைப்பாலும் சரிசெய்ய முடியாது.

reboot நிலுவையில் உள்ளதா என்பதை எவ்வாறு கண்டறிவது?

Live patching அவசரத் தேவையை நீக்குவதால், reboot தேவைப்படுவது வெளிப்படையாகத் தெரியாது. நீங்களே அதைச் சரிபார்க்க வேண்டும்.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

ஒரு package நிறுவப்பட்ட பிறகு அதைச் செயல்படுத்த restart தேவைப்படும்போது, package manager /var/run/reboot-required-ஐ உருவாக்குகிறது. புதிய linux-image package எப்போதும் இதை உருவாக்கும். எந்தெந்த packages reboot கோரியுள்ளன என்பதை .pkgs கோப்பு பட்டியலிடும். முதல் கட்டளை No such file or directory என்று பதிலளித்தால், கடைசியாக machine reboot செய்யப்பட்டதிலிருந்து எந்தப் புதிய reboot-ம் கோரப்படவில்லை என்று அர்த்தம். தற்போதைய Ubuntu-வில் /var/run என்பது /run-க்கான ஒரு symlink ஆகும், எனவே எந்தப் பாதையைப் பயன்படுத்தினாலும் ஒரே கோப்பையே சென்றடையும்.

அந்த flag ஒரு tmpfs-ல் இருப்பதால், ஒவ்வொரு boot-ன் போதும் அது reset ஆகிவிடும். எனவே, kernel-ஐ வைத்தே இதை உறுதிப்படுத்தவும்:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r நீங்கள் தற்போது இயக்கும் kernel-ஐக் காட்டும். இரண்டாவது கட்டளை வட்டில் நிறுவப்பட்டுள்ள kernel packages-ஐப் பட்டியலிடும். அந்தப் பட்டியலில் uname -r காட்டும் பதிப்பை விடப் புதியதாக ஒரு linux-image இருந்தால், Livepatch-ன் நிலை எதுவாக இருந்தாலும், machine பழைய kernel-லேயே இயங்குகிறது என்று அர்த்தம். இதுவே மிக முக்கியமான சரிபார்ப்பு, ஏனெனில் live patching என்பது இயங்கும் kernel-ஐப் பாதுகாப்பாக வைத்திருக்கவே உருவாக்கப்பட்டது, அதைத் தற்போதைய பதிப்பிற்கு (current) மாற்ற அல்ல.

Userspace-ல் இதே கேள்வியைச் சரிபார்க்க, Ubuntu Server-ல் முன்னிருப்பாக நிறுவப்பட்டுள்ள needrestart-ஐப் பயன்படுத்தலாம். இது நீக்கப்பட்ட library கோப்புகளை இன்னும் பயன்படுத்திக்கொண்டிருக்கும் இயங்கும் services-ஐப் பட்டியலிடும்.

sudo needrestart -r l

-r l flag ஜோடி "list only" என்பதைக் குறிக்கிறது, எனவே இது எதையும் மாற்றாமல் தகவலை மட்டும் வழங்கும்.

reboot ஏன் தவிர்க்க முடியாதது

வட்டில் உள்ள kernel மாறாமல் அப்படியே இருக்கும். Live patches இயங்கும் kernel-ல் மட்டுமே ஏற்றப்படும்; அவை boot image-ல் எழுதப்படுவதில்லை. எனவே, bootloader எந்த linux-image-ஐத் தேர்ந்தெடுக்கிறதோ, அதிலேயே நீங்கள் reboot செய்கிறீர்கள். அதன் பிறகு, Livepatch client தற்போதைய சூழலுக்குப் பொருந்தும் patches-ஐ மீண்டும் நிறுவுகிறது. இந்த இரண்டு நிகழ்வுகளுக்கும் இடைப்பட்ட நேரத்தில், நீங்கள் patch செய்யப்படாத code-ஐ இயக்குகிறீர்கள். பழைய kernel-க்கு பதிலாக தற்போதைய kernel-ஐ boot செய்வதற்கு இதுவே கூடுதல் காரணம்.

ஒவ்வொரு kernel series-க்கும் தனித்தனியான coverage உண்டு, மேலும் அந்த series-கள் காலாவதியாகிவிடும். நீங்கள் இயக்கும் series ஆதரவு பட்டியலில் இருந்து நீக்கப்பட்டால், kernel state வரிசையில் coverage விவரங்கள் வராது. இதற்குப் புதிய kernel-க்கு மாறுவது மட்டுமே தீர்வு. அதற்கு reboot அவசியம்.

நடுத்தர மற்றும் குறைந்த பாதிப்பு கொண்ட kernel திருத்தங்கள் live patch செய்யப்படுவதில்லை. அவை வட்டில் உள்ள package-ல் அப்படியே இருக்கும்; நீங்கள் boot செய்யும்போது மட்டுமே அவை அமலுக்கு வரும்.

நீண்ட காலம் இயங்கும் kernel-களில் patching மூலம் நீக்க முடியாத state-கள் சேரக்கூடும். Canonical நிறுவனத்தின் நிலைப்பாட்டை மேற்கோள் காட்டுவது பொருத்தமானது, ஏனெனில் அதுவே உண்மையானது: Livepatch "என்பது reboot செய்வதற்கு மாற்றல்ல. திட்டமிடப்படாத reboot-களைத் தவிர்ப்பதன் மூலம் உங்களுக்கு அதிகக் கட்டுப்பாட்டை வழங்கும் ஒரு கருவி மட்டுமே." இதில் கவனிக்க வேண்டிய முக்கிய வார்த்தை திட்டமிடப்படாத (unscheduled) என்பதுதான். நீங்கள் reboot செய்யத்தான் வேண்டும். எப்போது என்பதை நீங்களே முடிவு செய்கிறீர்கள்.

மீண்டும் தொடங்கும் வகையில் reboot-ஐ திட்டமிடுதல்

நீங்கள் console-ஐ அணுக முடியாவிட்டால், VPS reboot என்பது ஒரு வழிப் பயணமாகிவிடும். reboot கட்டளையை உள்ளிடுவதற்கு முன், கணினி மீண்டும் தொடங்காத பட்சத்தில் உங்களால் உள்ளே நுழைய முடியும் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.

• உங்கள் service provider, control panel-ல் serial console அல்லது VNC (virtual network computing) வசதியை வழங்குகிறாரா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். சிக்கல் ஏற்படும் போது தேடுவதை விட, இப்போதே அதைத் திறந்து வைத்துக்கொள்ளுங்கள்.
• df -h /boot கட்டளையைப் பயன்படுத்தி காலியான இடத்தைச் சரிபார்க்கவும். /boot முழுமையாக நிரம்பியிருந்தால், kernel package அதன் initramfs (initial RAM filesystem)-ஐ எழுதும் போது தோல்வியடையும். இது முழுமையடையாத image-ஐக் காட்டும் bootloader entry-ஐ உருவாக்கிவிடும்.
• குறைந்தது ஒரு பழைய, சரியாக இயங்கும் kernel-ஐ நிறுவி வைத்திருக்கவும். GRUB அதை "Advanced options for Ubuntu" என்பதன் கீழ் பட்டியலிடும். புதிய kernel தோல்வியடையும் போது, அதைப் பயன்படுத்தி மீண்டும் தொடங்குவதே விரைவான மீட்பு முறையாகும்.
• தேவைப்படுவதற்கு முன்பே உங்கள் provider-ன் rescue mode-ஐக் கண்டறியவும். reboot-க்குப் பிறகு console-ல் initramfs prompt தெரிந்தால், அங்கேயே பழுதுபார்க்கும் பணிகளைச் செய்ய வேண்டும்.

நீங்கள் விழித்திருக்கும் நேரத்தில் reboot-ஐத் திட்டமிடுங்கள்:

sudo shutdown -r +5 "Kernel update, back in a moment"

இது ஐந்து நிமிடங்களுக்குப் பிறகு reboot-ஐத் திட்டமிட்டு, உள்நுழைந்திருக்கும் பயனர்களுக்கு ஒரு செய்தியை அனுப்பும். sudo shutdown -c கட்டளை அதை ரத்து செய்யும். கணினி மீண்டும் வந்ததும், இரண்டு பகுதிகளையும் உறுதிப்படுத்தவும்:

uname -r
sudo canonical-livepatch status

uname -r இப்போது புதிய kernel-ஐக் காட்ட வேண்டும், மேலும் status வெளியீடு புதிய series-ஐ உள்ளடக்கியதாக இருக்க வேண்டும். ஒருவேளை கணினி மீண்டும் வரவில்லை என்றால், பிழை பெரும்பாலும் network-ல் இருக்காது, boot path-ல் தான் இருக்கும். அதற்கான மீட்பு வழிமுறை kernel update-க்குப் பிறகு boot ஆகாத VPS-ஐச் சரிசெய்யும் வழிகாட்டி-ல் உள்ளது.

பழைய kernels ஏன் நீக்கப்பட வேண்டும்

Live patching இந்தச் சிக்கலைத் தீர்ப்பதற்குப் பதிலாக மோசமாக்குகிறது. ஏனெனில், linux-image packages தொடர்ந்து install செய்யப்படுவதால், server-ஐ reboot செய்ய வேண்டிய அவசியம் இல்லாமல் போகிறது. ஒவ்வொரு kernel-உம் ஒரு boot image, ஒரு initramfs, ஒரு modules tree மற்றும் பொதுவாக ஒரு headers package-ஐ install செய்கிறது. சில நூறு megabytes அளவுள்ள தனி /boot partition கொண்ட சிறிய VPS-களில், மூன்றோ நான்கோ kernels-ஐ install செய்தாலே அந்த partition நிரம்பிவிடும்.

ஒரு முழுமையான /boot அடுத்த kernel install-ஐத் தடுத்துவிடும். இதனால், ஒரு machine தனக்குத் தேவையான update-ஐயே செய்ய முடியாமல் போகிறது. apt autoremove கட்டளை பழைய kernels-ஐ நீக்கத் தகுதியுள்ளதாகக் கருதினால் மட்டுமே அவற்றை நீக்கும். ஆனால், ஒரு machine-ஐ reboot செய்யாதபோது, தற்போது இயங்கிக்கொண்டிருக்கும் kernel-ஐ package manager நீக்காது என்பதால், பழைய kernels அங்கேயே தங்கிவிடும்.

எனவே, எவை install செய்யப்பட்டுள்ளன என்பதைச் சரிபார்க்கவும். தற்போது இயங்கும் kernel மற்றும் நன்கு செயல்படும் ஒரு fallback kernel ஆகியவற்றை மட்டும் வைத்துக்கொண்டு, மற்றவற்றை Ubuntu-வில் பழைய kernels-ஐ நீக்குவதற்கான பாதுகாப்பான வழிமுறை மூலம் நீக்கவும். uname -r எதைக் காட்டுகிறதோ, அந்த kernel-ஐ ஒருபோதும் நீக்க வேண்டாம்.

FAQ

Live kernel patching செய்வதால் எனது VPS-ஐ நான் ஒருபோதும் reboot செய்ய வேண்டியதில்லை என்று அர்த்தமா?

இல்லை. Live patches இயங்கும் kernel-க்குள் ஏற்றப்படுகின்றன, அவை boot image-ல் எழுதப்படுவதில்லை. எனவே, வட்டில் உள்ள linux-image நீங்கள் எந்தப் பதிப்பில் boot செய்தீர்களோ அதே பதிப்பில் இருக்கும். Canonical இதைத் தெளிவாகக் கூறுகிறது: Livepatch "reboot செய்வதற்கு மாற்றானது அல்ல. இது திட்டமிடப்படாத reboot-களைத் தவிர்ப்பதன் மூலம் உங்களுக்கு அதிகக் கட்டுப்பாட்டை வழங்கும் ஒரு கருவி." உங்கள் kernel series பயன்பாட்டிலிருந்து நீக்கப்படும்போது இதற்கான ஆதரவும் முடிந்துவிடும். நடுத்தர தீவிரத்தன்மை கொண்ட kernel திருத்தங்கள் (medium severity fixes) எப்போதுமே live patch செய்யப்படுவதில்லை. கட்டாயப்படுத்தப்படும் வரை காத்திருக்காமல், நீங்களே ஒரு கால அட்டவணையை உருவாக்கி maintenance reboot-ஐத் திட்டமிடுங்கள்.

Live kernel patching உண்மையில் patches-ஐப் பொருத்துகிறதா என்பதை நான் எப்படிச் சரிபார்ப்பது?

sudo canonical-livepatch status கட்டளையை இயக்கி இரண்டு வரிகளைப் படிக்கவும். உங்கள் இயங்கும் kernel series இந்தச் சேவையின் கீழ் வருகிறதா என்பதை kernel state தெரிவிக்கும், மேலும் அந்த kernel-க்கான patches ஏற்றப்பட்டுள்ளதா என்பதை patch state தெரிவிக்கும். நீங்கள் ls /sys/kernel/livepatch/ கட்டளையைப் பயன்படுத்தி kernel பக்கத்தையும் நேரடியாகச் சரிபார்க்கலாம்; இது ஏற்றப்பட்ட ஒவ்வொரு patch-க்கும் ஒரு directory-ஐப் பட்டியலிடும். பட்டியல் காலியாக இருந்தால், client என்ன சொன்னாலும், தற்போது நினைவகத்தில் (memory) எந்த patch-ம் இல்லை என்று அர்த்தம்.

தனிப்பட்ட VPS-ல் Ubuntu Pro இலவசமா?

ஆம், ஆவணப்படுத்தப்பட்ட வரம்பிற்குள் இது இலவசம். Canonical-ன் கூற்றுப்படி, Ubuntu Pro "தனிப்பட்ட பயன்பாட்டிற்கு 5 physical machines வரை எப்போதும் இலவசம்". ஆகஸ்ட் 2026 நிலவரப்படி, அதிகாரப்பூர்வ Ubuntu Community உறுப்பினர்களுக்கு இது 50 machines வரை உயர்கிறது. வணிக ரீதியான பயன்பாட்டிற்கு கட்டணச் சந்தா தேவை. உங்கள் Ubuntu Pro கணக்குப் பக்கத்திலிருந்து ஒரு token-ஐப் பெற்று sudo pro attach TOKEN மூலம் machine-ஐ இணைக்க வேண்டும், பின்னர் sudo pro enable livepatch மூலம் சேவையை இயக்க வேண்டும்.

Livepatch இயங்கிய பிறகும் ஒரு kernel CVE ஏன் இன்னும் சரிசெய்யப்படாததாகக் காட்டப்படுகிறது?

பொதுவாக இரண்டு காரணங்கள் இருக்கலாம். Canonical "critical மற்றும் high CVSS மற்றும் Ubuntu Priority மதிப்பீடுகளைக் கொண்ட kernel பாதிப்புகளை" மட்டுமே live patch செய்கிறது, மற்றவற்றை வட்டில் உள்ள package-ன் பொறுப்பிற்கு விட்டுவிடுகிறது. எனவே, அந்தத் திருத்தம் தீவிரத்தன்மை வரம்பிற்கு கீழே இருக்கலாம். அல்லது, upstream ஒரு data structure-ஐ மாற்றியமைத்திருந்தால், அதை function body மாற்றமாக மட்டும் வெளிப்படுத்த முடியாது; ஏற்கனவே ஒதுக்கப்பட்ட objects-ல் இதை live patching மூலம் பாதுகாப்பாகச் செய்ய முடியாது. இரண்டு சூழல்களிலும் ஒரே தீர்வுதான்: மேம்படுத்தப்பட்ட kernel package-ஐ நிறுவி, அதில் boot செய்யவும்.

Live kernel patching எதை உள்ளடக்குவதில்லை?

Userspace-ஐ இது உள்ளடக்குவதில்லை. Livepatch "OpenSSL அல்லது glibc போன்ற userspace libraries-ஐப் patch செய்வதில்லை, ஏனெனில் அது unattended-upgrades அல்லது ஒரு systems management கருவியின் பொறுப்பாகும்" என்று Canonical தெளிவாகக் கூறுகிறது. இது புதிய kernel பதிப்பையோ அல்லது புதிய அம்சங்களையோ வழங்க முடியாது, ஏனெனில் இது நீங்கள் ஏற்கனவே இயக்கும் series-க்குள் இருக்கும் function bodies-ஐ மட்டுமே மாற்றுகிறது. மேலும், இது __init functions-ஐப் patch செய்ய முடியாது, ஏனெனில் server இயங்கத் தொடங்கும்போதே அவை இயங்கி நினைவகத்திலிருந்து நீக்கப்பட்டிருக்கும்.