VPS वर live kernel patching की reboot: काय निवडावे?

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

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

यामुळे वेळ मिळतो. मात्र reboot ची आवश्यकता संपत नाही. सहा महिने live patched असलेला server disk वरील जुन्या kernel image वरच boot झालेला असतो. तसेच त्या सर्व patches फक्त memory मध्येच असतात.

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

थेट kernel patching कसे कार्य करते?

kernel मध्ये live patching साठी built-in core असतो. तो CONFIG_LIVEPATCH सह compile केलेला असतो. तुमच्या चालू kernel मध्ये तो उपलब्ध आहे का ते तपासा:

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

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

Code redirection साठी ftrace वापरले जाते. ftrace हा kernel मधील function tracer आहे. बहुतेक kernel functions च्या अगदी सुरुवातीला call instruction compile केलेले असते. त्या वेळी arguments किंवा stack मध्ये अद्याप कोणताही बदल झालेला नसतो. ftrace या call site चा hook म्हणून वापर करते. Patch लागू केल्यावर live patching core target function वर ftrace handler नोंदवतो. त्यानंतर हा handler execution ऐवजी replacement function कडे पाठवतो. Kernel 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."

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

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

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

ls /sys/kernel/livepatch/

यादी रिकामी असल्यास memory मध्ये कोणताही live patch load केलेला नाही. नवीन server वर हीच सामान्य प्रारंभिक स्थिती असते.

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

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

• बदललेल्या 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 संपूर्ण मशीन एका क्षणी थांबवण्याऐवजी tasks मध्ये बदल लागू करतो.
• 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 मानला जात नाही. त्यामुळे त्याच box वर 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 चे कोणते पर्याय उपलब्ध आहेत?

सामान्यतः तीन lineage वापरले जातात आणि ते तिन्ही समान 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 साठी coverage देतो, ज्यात 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 कोणत्या पर्यायाला समर्थन देते आणि तुमची licence कोणता वापर अनुमत करते यावर आधारित निवड करा. प्रत्येक पर्यायात kernel स्तरावरील परिणाम समान असतो.

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

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

sudo pro attach TOKEN
sudo pro status

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

Livepatch आधीपासून enabled नसेल तर:

sudo pro enable livepatch
sudo canonical-livepatch status

ही service canonical-livepatch snap मधून चालते. त्यामुळे enable step पूर्ण होण्यासाठी snapd कार्यरत असणे आवश्यक आहे. pro status services ची entitlement आणि status यांसह 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 पॅकेज नेहमीच तो तयार करते. कोणत्या पॅकेजने ही विनंती केली आहे, याची यादी .pkgs फाइलमध्ये असते. पहिल्या command चे उत्तर No such file or directory असल्यास, मशीनच्या शेवटच्या boot नंतर कोणत्याही पॅकेजने रीबूटची विनंती केलेली नाही. सध्याच्या Ubuntu मध्ये /var/run हा /run कडे निर्देश करणारा symlink आहे. त्यामुळे दोन्ही paths मधून त्याच फाइलपर्यंत पोहोचता येते.

हा 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 पेक्षा नवीन आवृत्ती सूचित केली, तर Livepatch ची स्थिती काहीही असली तरी मशीन जुना kernel चालवत आहे. हीच महत्त्वाची तपासणी आहे. Live patching चे उद्दिष्ट चालू kernel सुरक्षित ठेवणे आहे; तो current ठेवणे नाही.

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

sudo needrestart -r l

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

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

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

Coverage प्रत्येक kernel series साठी स्वतंत्र असते आणि series निवृत्त होतात. तुमची चालू series supported list मधून काढली गेल्यावर kernel state line coverage दाखवणे थांबवते. यावर एकमेव उपाय म्हणजे नवीन kernel वापरणे. त्यासाठी reboot आवश्यक असतो.

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

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

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

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

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

त्यानंतर तुम्ही जागे असाल अशा वेळी रीबूटचे वेळापत्रक ठरवा:

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

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

uname -r
sudo canonical-livepatch status

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

जुने kernels अजूनही का काढून टाकावे लागतात

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

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

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

FAQ

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

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

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

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

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

होय, परंतु documented limit अंतर्गत. Canonical च्या मते Ubuntu Pro "personal use साठी 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 live patches "critical आणि high Common Vulnerability Scoring System (CVSS) तसेच Ubuntu Priority ratings असलेल्या kernel vulnerabilities वर लागू करते" आणि उर्वरित fixes disk वरील package कडे सोपवते. किंवा function body मध्ये बदल करून fix व्यक्त करता येत नसेल. उदाहरणार्थ, upstream ने data structure बदलल्यास, आधीच allocate केलेल्या objects वर असा बदल सुरक्षितपणे करता येत नाही. दोन्ही परिस्थितींमध्ये उपाय एकच आहे: updated kernel package install करा आणि त्यामध्ये boot करा.

Live kernel patching नेमके काय cover करत नाही?

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