VPS वर live kernel patching की reboot?

VPS वर live kernel patching काय करते

Live kernel patching मुळे चालू मशीनवर kernel security fixes लागू करता येतात. यासाठी reboot आवश्यक नसतो आणि connections तुटत नाहीत. एखाद्या function ची दुरुस्त केलेली copy kernel module म्हणून load केली जाते. त्यानंतर जुन्या function ला होणारा प्रत्येक call नवीन copy कडे वळवला जातो. हे घडत असतानाही server network traffic स्वीकारत राहतो. Live patching कशासाठी उपयुक्त आहे आणि ते काय करू शकत नाही, हे दोन्ही याच यंत्रणेमुळे स्पष्ट होते.

यामुळे वेळ मिळतो. मात्र reboot ची गरज संपत नाही. एखाद्या server वर सहा महिने live patching केलेले असले, तरी disk वरील जुन्या kernel image वरच त्याने boot केलेले असते. तसेच हे सर्व patches केवळ memory मध्येच असतात.

Live patching हे managed plan मधील feature म्हणून अनेकदा दिले जाते. Unmanaged box वर तुम्ही ते दोन commands ने स्वतः enable करू शकता. त्यामुळे managed आणि unmanaged VPS मधील फरक यासाठी पैसे देण्यापूर्वी ही बाब जाणून घेणे उपयुक्त ठरते.

लाइव्ह कर्नल पॅचिंग कसे कार्य करते?

कर्नलमध्ये लाइव्ह पॅचिंगसाठी built-in core असतो आणि तो CONFIG_LIVEPATCH सह compile केलेला असतो. तुमच्या चालू कर्नलमध्ये तो core आहे का ते तपासा:

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

CONFIG_LIVEPATCH=y अशी ओळ दिसत असल्यास, तुम्ही चालवत असलेला कर्नल हा core उपलब्ध असताना build केलेला आहे. हा core नसल्यास, त्या मशीनवर कोणतीही live patching service काम करू शकत नाही.

कोडचे redirection कर्नलच्या function tracer असलेल्या ftrace चा वापर करते. बहुतेक कर्नल functions च्या अगदी सुरुवातीला call instruction compile केलेले असते. त्या वेळी arguments किंवा stack मध्ये अद्याप बदल झालेला नसतो. ftrace त्या call site चा hook म्हणून वापर करते. पॅच लागू केल्यावर live patching core target function वर ftrace handler नोंदवतो. त्यानंतर handler execution ऐवजी replacement function कडे पाठवतो. कर्नल documentation मध्ये हे स्पष्टपणे सांगितले आहे: "Livepatching typically needs to redirect the code at the very beginning of the function entry before the function parameters or the stack are in any way modified."

या वाक्यातून दोन परिणाम दिसून येतात आणि पुढील प्रक्रियेसाठी दोन्ही महत्त्वाचे आहेत. ज्या function ला ftrace hook करू शकते, तीच function patch करता येते. त्यामुळे entry call शिवाय compile केलेली function अजिबात patch करता येत नाही. तसेच patching unit ही संपूर्ण function असते; तिच्यातील एकच line कधीही स्वतंत्रपणे patch केली जात नाही.

Live system सुरक्षितपणे बदलणे हा अधिक कठीण भाग आहे. Function बदलताना एखाद्या CPU च्या stack वर जुना code अजून चालू असेल, तर old आणि new behaviour एकत्र येऊ शकते. Upstream Linux हे per-task consistency model वापरून हाताळते. Kernel docs मध्ये याचे वर्णन hybrid model म्हणून केले आहे: "it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." एखादे task patched function च्या आत सध्या कार्यरत नाही, हे कर्नल दाखवू शकते तेव्हाच ते task एकावेळी नवीन code कडे हलवले जाते. सर्व tasks हलवेपर्यंत patch transition मध्ये असतो.

याचा परिणाम तुम्ही स्वतः पाहू शकता. लागू केलेले patches /sys/kernel/livepatch अंतर्गत दिसतात. प्रत्येक patch साठी स्वतंत्र directory असते आणि त्यामध्ये patched functions ची यादी असते.

ls /sys/kernel/livepatch/

Listing रिकामी असल्यास memory मध्ये कोणताही live patch loaded नाही. Fresh server साठी ही सामान्य प्रारंभिक स्थिती असते.

लाइव्ह कर्नल पॅचिंग कोणत्या समस्या सोडवू शकत नाही

फंक्शनच्या body मध्ये पॅच लागू करता येतो. इतर कोणत्याही गोष्टीवर पॅच लागू करता येत नाही.

• बदललेल्या data structures. Upstream fix मुळे एखाद्या struct मध्ये field जोडला गेला किंवा विद्यमान field चा अर्थ बदलला, तर आधीच allocate करून वापरात असलेल्या objects ची रचना सुरक्षितपणे बदलण्याचा कोणताही मार्ग नसतो. kpatch project याच बाबतीत स्पष्टपणे सांगतो: "Patches which modify statically allocated data are not directly supported." Shadow variables आणि callbacks हा workaround म्हणून वापरता येतात. मात्र ते प्रत्येक patch साठी स्वतंत्रपणे लिहावे लागतात आणि ते automatic नसतात.
• एकाच वेळी अनेक functions मध्ये बदल आवश्यक असलेले fixes. Functions च्या समूहामध्ये lock ordering बदलणाऱ्या fix साठी त्या सर्व functions मध्ये एकाच वेळी बदल करावे लागतात. Consistency model संपूर्ण मशीन एका क्षणी freeze करण्याऐवजी tasks switch करते.
• Initialisation code. __init म्हणून चिन्हांकित functions तुमचा server सुरू होईपर्यंत आधीच चालून पूर्ण झालेल्या आणि मुक्त केलेल्या असतात. त्यामुळे redirect करण्यासाठी काहीही शिल्लक राहत नाही.
• नवीन kernel versions आणि नवीन features. Live patching मुळे तुम्ही एका kernel series मधील patch level वर पुढे जाता. ते तुम्हाला एका series मधून पुढील series मध्ये नेत नाही आणि कोणतेही feature जोडत नाही. नवीन series मधील एखादी गोष्ट हवी असल्यास, उदाहरणार्थ Linux 7.1 मध्ये समाविष्ट झालेले बदल, तो kernel install करून boot करावा लागतो.
• Userspace. Canonical ही मर्यादा स्पष्टपणे सांगते: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." जुन्या OpenSSL च्या शेजारी live patched kernel असला, तरी तो patched server ठरत नाही. त्यामुळे त्याच machine वरील userspace packages चे व्यवस्थापन unattended upgrades कडे सोपवा.

Ubuntu च्या service साठी severity ची मर्यादाही आहे. Canonical सांगते की ते "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." CVE (common vulnerabilities and exposures) identifier एका flaw चे नाव दर्शवतो आणि CVSS त्याला दिलेला score असतो. Medium-rated kernel CVE disk वरील package मध्ये fixed केला जातो; त्यावर live patch लागू केला जात नाही. त्यामुळे तो तुमच्या running kernel मध्ये पुढील reboot वेळी लागू होतो, त्यापूर्वी नाही.

थेट kernel patchingचे पर्याय कोणते आहेत?

सामान्य वापरात तीन प्रमुख पद्धती आहेत आणि त्या सर्व एकाच kernel यंत्रणेचा वापर करतात.

Canonical Livepatch हे Ubuntu Pro द्वारे उपलब्ध केले जाते. वैयक्तिक वापरासाठी Ubuntu Pro विनामूल्य आहे. Canonicalच्या मते, ते “वैयक्तिक वापरासाठी कमाल 5 physical machines वर सधैव विनामूल्य आहे”; अधिकृत Ubuntu Community सदस्यांसाठी ही मर्यादा 50 machines पर्यंत वाढते. August 2026 पर्यंत ही दस्तऐवजीकृत मर्यादा आहे. व्यावसायिक वापरासाठी सशुल्क subscription आवश्यक आहे. Coverage प्रत्येक kernel series आणि flavour साठी स्वतंत्रपणे दिले जाते. यात समर्थित long term support (LTS) releasesचे general availability (GA) kernels आणि त्यांचे hardware enablement (HWE) kernels समाविष्ट असतात. generic, aws, azure, gcp, oracle, ibm आणि lowlatency यांसारखे flavours यामध्ये येतात. त्यावर अवलंबून राहण्यापूर्वी तुमचा kernel Canonicalच्या प्रकाशित kernel listशी जुळतो का ते तपासा.

KernelCare, जे TuxCareकडून उपलब्ध केले जाते, हा commercial agent आहे. तो अनेक distributionsना support करतो; त्यात first-party service नसलेल्या distributionsचाही समावेश आहे. त्याची दस्तऐवजीकृत installation vendor script, curl -s -L https://kernelcare.com/installer | bash, चालवून केली जाते. त्यानंतर key-based licence साठी /usr/bin/kcarectl --register KEY चालवले जाते. Agent स्वतःच्या scheduleनुसार नवीन patches तपासतो आणि /usr/bin/kcarectl --update वापरल्यास तपासणी सक्तीने सुरू होते. महत्त्वाच्या serverवर installer shellकडे pipe करण्यापूर्वी तो वाचा.

kpatch आणि kGraft हे या तंत्रज्ञानाचे पूर्वज आहेत. kGraft SUSEकडून आले आणि kpatch Red Hatकडून. आजच्या upstream Linuxमधील live patching core ही दोन्ही संकल्पनांच्या एकत्रीकरणातून तयार झाली आहे. kpatch स्वतः हळूहळू बंद होत आहे. त्याच्या READMEनुसार, Linux 6.19 पासून “kpatch project is deprecated and in maintenance mode” आणि upstream kernelमध्ये kpatch-build ऐवजी klp-build वापरले जात आहे. RHEL आणि त्यावर आधारित rebuildsमध्ये patches स्वतः तयार करण्याऐवजी distributionची स्वतःची service वापरा.

तुमची distribution कोणत्या पर्यायाला support करते आणि तुमची licence कोणता वापर परवानगी देते यावरून निवड करा. प्रत्येक पर्यायामध्ये kernel स्तरावरील परिणाम समान असतो.

Ubuntu वर Canonical Livepatch कसे सक्षम करावे

प्रथम तुमच्या Ubuntu Pro account page वरून token मिळवा. खालील दोन्ही commands साठी कार्यरत outbound network access आवश्यक आहे, कारण client attach करण्यासाठी आणि patches मिळवण्यासाठी Canonical च्या servers शी संवाद साधतो.

sudo pro attach TOKEN
sudo pro status

sudo pro attach token शिवाय चालवल्यास त्याऐवजी browser-based flow सुरू होतो आणि Canonical च्या site वर प्रविष्ट करण्यासाठी code दाखवला जातो. Attaching केल्यावर शिफारस केलेल्या services आपोआप सक्षम होतात. सध्याच्या LTS release मध्ये यामध्ये Livepatch समाविष्ट असते. Services स्वतः निवडायच्या असल्यास sudo pro attach --no-auto-enable वापरा.

Livepatch आधीपासून सक्षम नसेल तर:

sudo pro enable livepatch
sudo canonical-livepatch status

ही service canonical-livepatch snap मधून चालते. त्यामुळे enable step पूर्ण होण्यासाठी snapd कार्यरत असणे आवश्यक आहे. pro status त्यांच्या entitlement आणि status सह services ची table दाखवते. canonical-livepatch status प्रत्येक kernel चा तपशील दाखवते. Canonical च्या documentation मध्ये output या स्वरूपात दाखवले आहे:

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

याचे उत्तर दोन lines मध्ये मिळते. kernel state तुम्ही चालवत असलेली series ही service मुळात support करते का ते सांगते. Livepatch support करत नसलेला kernel boot केल्यावर ही line अपयशी स्थिती दाखवते. patch state त्या kernel साठी लागू होणारे patches प्रत्यक्षात loaded आहेत का ते सांगते. Covered kernel वर कोणतेही patches लागू नसतील, तर समस्या client मध्ये आहे. Kernel uncovered असेल, तर समस्या kernel मध्ये आहे; कोणतीही client setting ती दुरुस्त करू शकत नाही.

रीबूट प्रलंबित आहे की नाही हे कसे तपासावे?

Live patching मुळे आपत्कालीन रीबूटची गरज कमी होते. त्यामुळे रीबूट प्रलंबित आहे हे लगेच लक्षात येत नाही. ते तपासावे लागते.

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

स्थापित पॅकेज लागू होण्यासाठी रीस्टार्ट आवश्यक असल्यास package manager /var/run/reboot-required तयार करतो. नवीन linux-image package नेहमी ही फाइल तयार करते. कोणत्या पॅकेजने विनंती केली आहे, याची यादी .pkgs फाइलमध्ये असते. पहिल्या command चा परिणाम No such file or directory असल्यास, मशीनच्या शेवटच्या boot नंतर कोणत्याही पॅकेजने रीबूटची विनंती केलेली नाही. सध्याच्या Ubuntu मध्ये /var/run हा /run कडे निर्देश करणारा symlink आहे. त्यामुळे दोन्ही path ने त्याच फाइलपर्यंत पोहोचता येते.

हा flag tmpfs मध्ये साठवला जातो आणि प्रत्येक boot वेळी reset होतो. त्यामुळे तो kernel च्या स्थितीशी पडताळा:

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

uname -r command सध्या चालू असलेला kernel दाखवतो. दुसरा command disk वर स्थापित असलेली kernel packages दाखवतो. त्या यादीतील linux-image ने uname -r ने दाखवलेल्या kernel पेक्षा नवीन kernel दाखवला, तर मशीन जुना kernel चालवत आहे. Livepatch ची स्थिती काहीही असो, हेच घडत आहे. ही तपासणी महत्त्वाची आहे, कारण live patching चे उद्दिष्ट चालू kernel सुरक्षित ठेवणे आहे; तो अद्ययावत ठेवणे नाही.

याच प्रश्नाच्या userspace भागासाठी, needrestart हे Ubuntu Server वर default ने स्थापित असते. ते deleted library files अजूनही उघड्या ठेवणाऱ्या चालू services ची यादी दाखवते.

sudo needrestart -r l

-r l ही flag pair “फक्त यादी दाखवा” असा अर्थ देते. त्यामुळे ती कोणताही बदल करत नाही.

रीबूटची गरज कधीच का संपत नाही

डिस्कवरील kernel बदललेला नसतो. Live patches कार्यरत kernel मध्ये लोड केले जातात आणि boot image मध्ये कधीही लिहिले जात नाहीत. त्यामुळे reboot केल्यावर bootloader ज्या linux-image ला निवडतो, त्यावर प्रणाली सुरू होते. त्यानंतर Livepatch client लागू असलेले patches पुन्हा लागू करतो. या दोन क्षणांदरम्यान प्रणाली unpatched code चालवत असते. जुन्या kernel ऐवजी current kernel वर boot करण्याचे हे आणखी एक कारण आहे.

Coverage प्रत्येक kernel series साठी स्वतंत्र असते आणि series निवृत्त होतात. तुमची कार्यरत series समर्थित यादीतून बाहेर पडल्यावर kernel state ओळ coverage दाखवणे थांबवते. यावर एकमेव उपाय म्हणजे newer kernel वापरणे. यासाठी reboot आवश्यक असतो. LTS release मध्ये newer series सहसा hardware enablement kernel म्हणून 26.04.1 सारख्या point release मध्ये समाविष्ट होऊन तुमच्यापर्यंत पोहोचते. त्यामुळे replacement आधीच archive मध्ये उपलब्ध असतो आणि फक्त नियोजित boot बाकी असतो.

Medium आणि low severity kernel fixes कधीही live patched केले जात नाहीत. ते डिस्कवरील package मध्ये राहतात आणि तुम्ही boot केल्यावरच लागू होतात.

दीर्घकाळ चालणारे kernels अशी state साठवतात जी patching मुळे साफ होत नाही. Canonical ची स्वतःची भूमिका येथे उद्धृत करणे योग्य आहे, कारण ती स्पष्ट आहे: Livepatch "रीबूट करण्याचा पर्याय नाही. नियोजित नसलेले reboots टाळून अधिक नियंत्रण देणारे हे एक साधन आहे." येथे अर्थ स्पष्ट करणारा शब्द नियोजित नसलेले हा आहे. तुम्हाला तरीही reboot करावा लागतो. तो कधी करायचा हे तुम्ही ठरवता.

रीबूटचे वेळापत्रक कसे ठरवावे आणि सर्व्हर पुन्हा सुरू होईल याची खात्री कशी करावी

कन्सोलपर्यंत पोहोचता येत नसेल, तर VPS चे reboot करणे एकतर्फी ठरू शकते. reboot टाइप करण्यापूर्वी, मशीन पुन्हा सुरू न झाल्यास तुम्ही त्यात पुन्हा प्रवेश करू शकता याची खात्री करा.

• तुमचा provider control panel मध्ये serial console किंवा VNC (virtual network computing) view देतो का ते तपासा आणि outage सुरू झाल्यावर नव्हे, तर आत्ताच ते उघडा.
• df -h /boot वापरून उपलब्ध space तपासा. /boot भरलेले असल्यास kernel package त्याचे initramfs (initial RAM filesystem) लिहिताना fail होऊ शकते. त्यामुळे कधीही पूर्ण न झालेल्या image कडे निर्देश करणारी bootloader entry तयार होऊ शकते.
• किमान एक पूर्वीचा, व्यवस्थित काम करणारा kernel installed ठेवा. GRUB मध्ये तो "Advanced options for Ubuntu" अंतर्गत दिसतो. नवीन kernel fail झाल्यास त्यातून boot करणे हा recovery करण्याचा सर्वात जलद मार्ग आहे.
• गरज पडण्यापूर्वीच तुमच्या provider चा rescue mode शोधून ठेवा. reboot नंतर console वर initramfs prompt दिसल्यास repair तिथेच करावी लागते.

तुम्ही जागे असाल अशा वेळी reboot चे वेळापत्रक ठरवा:

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

यामुळे पाच मिनिटांनंतर reboot होईल आणि logged-in users ना message पाठवला जाईल. sudo shutdown -c वापरून ते रद्द करता येते. मशीन पुन्हा सुरू झाल्यावर दोन्ही बाबींची पडताळणी करा:

uname -r
sudo canonical-livepatch status

uname -r ने आता नवीन kernel दाखवला पाहिजे आणि status output मध्ये नवीन series covered असल्याचे दिसले पाहिजे. मशीन अजिबात पुन्हा सुरू होत नसेल, तर fault जवळजवळ नेहमी network ऐवजी boot path मध्ये असतो. अशा वेळी recovery साठी kernel update नंतर boot न होणाऱ्या VPS साठीचे मार्गदर्शन वापरा.

जुने kernels अजूनही साफ करणे का आवश्यक आहे

Live patching मुळे ही समस्या कमी होण्याऐवजी वाढते, कारण linux-image packages install होत असताना reboot करण्याची गरज भासत नाही. प्रत्येक kernel सोबत boot image, initramfs, modules tree आणि सामान्यतः headers package install होते. काहीशे megabytes च्या स्वतंत्र /boot partition असलेल्या छोट्या VPS वर यांपैकी तीन किंवा चार packages ती partition भरतात.

/boot भरल्यावर पुढील kernel install अयशस्वी होते. त्यामुळे मशीनला आवश्यक असलेले update देखील install करता येत नाही. apt autoremove path पात्र झाल्यावर जुने kernels काढतो. मात्र ज्या मशीनचा कधीही reboot होत नाही, तिथे ते नेहमी पात्र झालेले नसतात. याचे कारण म्हणजे package manager सध्या वापरात असलेला kernel अजूनही चालू असण्याची शक्यता असल्याने तो काढत नाही.

म्हणून install केलेले kernels तपासा, सध्या चालू असलेला kernel आणि एक ज्ञात-स्थिर fallback ठेवा, आणि उरलेले kernels Ubuntu वर जुने kernels काढण्याची सुरक्षित पद्धत वापरून काढा. uname -r सध्या दाखवत असलेला kernel कधीही काढू नका.

FAQ

लाइव्ह kernel patching म्हणजे माझ्या VPS ला पुन्हा कधीही reboot करण्याची गरज नाही का?

नाही. लाइव्ह patches चालू kernel मध्ये load होतात आणि boot image मध्ये लिहिले जात नाहीत. त्यामुळे डिस्कवरील linux-image तुम्ही boot केलेल्या आवृत्तीवरच राहते. Canonical हे स्पष्टपणे सांगते: Livepatch "reboot करण्याचा पर्याय नाही. अनियोजित reboots रोखून अधिक नियंत्रण देणारे हे एक tool आहे." तुमची kernel series retired झाल्यावर coverage देखील समाप्त होते. तसेच medium severity kernel fixes साठी कधीही live patch लागू केला जात नाही. reboot सक्तीने होण्याची वाट पाहण्याऐवजी, तुम्ही ठरवलेल्या वेळापत्रकानुसार maintenance reboot नियोजित करा.

लाइव्ह kernel patching प्रत्यक्षात patches लागू करत आहे का हे कसे तपासायचे?

sudo canonical-livepatch status चालवा आणि दोन ओळी वाचा. kernel state तुमची चालू kernel series या service अंतर्गत covered आहे का हे दाखवते. patch state त्या kernel साठीचे patches load झाले आहेत का हे दाखवते. ls /sys/kernel/livepatch/ वापरून kernel कडील स्थिती थेट तपासू शकता. हा command load केलेल्या प्रत्येक patch साठी एक directory दाखवतो. Listing रिकामी असल्यास, client काहीही सांगत असला तरी, त्या क्षणी memory मध्ये कोणताही patch लागू केलेला नाही.

वैयक्तिक VPS वर Ubuntu Pro विनामूल्य आहे का?

होय, परंतु documented limit अंतर्गत. Canonical च्या मते Ubuntu Pro "वैयक्तिक वापरासाठी 5 physical machines पर्यंत विनामूल्य आहे आणि कायम विनामूल्य राहील." August 2026 पर्यंत official Ubuntu Community members साठी ही मर्यादा 50 machines आहे. Commercial use साठी paid subscription आवश्यक आहे. Ubuntu Pro account page वरील token वापरून sudo pro attach TOKEN सह machine attach करा. त्यानंतर sudo pro enable livepatch वापरून service enable करा.

Livepatch चालवल्यानंतरही kernel CVE unfixed म्हणून का दाखवला जातो?

साधारणपणे दोनपैकी एक कारण असते. Fix severity threshold पेक्षा कमी असू शकतो. Canonical "critical आणि high Common Vulnerability Scoring System (CVSS) तसेच Ubuntu Priority ratings असलेल्या kernel vulnerabilities" साठी live patches लागू करते आणि उर्वरित fixes डिस्कवरील package कडे सोपवते. किंवा fix हा function body मधील बदल म्हणून व्यक्त करता येत नसेल. उदाहरणार्थ, upstream ने data structure बदलला असल्यास, आधीच allocate केलेल्या objects वर असा बदल सुरक्षितपणे करता येत नाही. दोन्ही प्रकरणांत उपाय समान आहे: updated kernel package install करा आणि त्यात boot करा.

लाइव्ह kernel patching कोणत्या गोष्टी अजिबात cover करत नाही?

Userspace. Canonical स्पष्टपणे सांगते की Livepatch "OpenSSL किंवा glibc सारख्या userspace libraries वर patches लागू करत नाही, कारण त्याची जबाबदारी unattended-upgrades किंवा systems management tool ची आहे." तसेच ते नवीन kernel version किंवा नवीन feature देऊ शकत नाही. कारण तुम्ही आधीच चालवत असलेल्या series मधील function bodies तेवढ्याच बदलते. __init functions वरही patch लागू करता येत नाही. Server सुरू होईपर्यंत हे functions आधीच execute होऊन memory मधून मुक्त झालेले असतात.