O actualizare a kernelului SLES poate afișa în continuare „reboot needed” (repornire necesară) după activarea Live Patching. Aceasta nu înseamnă automat că configurarea a eșuat: patch-urile live acoperă doar remedierile pe care SUSE le poate livra în siguranță pentru kernelul care rulează în prezent, în timp ce un kernel de înlocuire sau remedierile care nu pot fi actualizate prin live-patch necesită în continuare o repornire. Ghidul SLES 16.0 Kernel Live Patching de la SUSE, publicat pe 8 octombrie 2026, oferă o cale de configurare mai nouă: instalați kernel_livepatchingmodelul sub abonamentul standard SLES. SLES 15 SP7 utilizează o extensie Live Patching separată și lp_slesmodelul.
Folosește procedura pentru versiunea exactă, aplică actualizările prin fluxul de lucru normal al pachetului SUSE și verifică patch-ul activ cu klp -v patches. Acești pași presupun o gazdă SLES înregistrată cu acces la depozitele de actualizări acceptate.
Identificați versiunea și kernelul care rulează. Executați:
cat /etc/os-release
uname -r
uname -m
Înregistrați versiunea SLES, versiunea kernelului și arhitectura. Pachetele de patch-uri live se potrivesc cu o revizie specifică a kernelului, astfel încât un pachet pentru un kernel diferit nu dovedește că kernelul activ este actualizat. Comenzile de mai jos utilizează instrucțiunile actuale SLES 16.0 și SLES 15 SP7; nu copiați un model sau o cale de activare specifică versiunii către o versiune diferită.
Pe SLES 16.0, instalați modelul inclus. Ghidul actual al SUSE spune că Kernel Live Patching este inclus în abonamentul standard SLES. Instalați modelul său:
sudo zypper install -t pattern kernel_livepatching
Dacă depozitele dvs. conțin un patch live eligibil pentru kernelul instalat, managerul de pachete îl selectează în timpul instalării; SUSE documentează faptul că kernelul este actualizat cu patch live ca parte a acestui proces. Nu există niciun cod de înregistrare Live Patching suplimentar în această procedură SLES 16.0.
Pe SLES 15 SP7, activați mai întâi extensia. Această versiune necesită abonamente active SLES și SLES Live Patching. Enumerați extensiile disponibile și utilizați comanda de activare specifică arhitecturii exactă pe care o afișează:
sudo SUSEConnect --list-extensions
sudo SUSEConnect -p sle-module-live-patching/15.7/x86_64 -r LIVE_PATCHING_REGISTRATION_CODE
A doua comandă este un exemplu x86_64. Înlocuiți-o cu calea exactă a produsului afișată în propria --list-extensionsieșire și furnizați codul de înregistrare Live Patching valid. Apoi instalați modelul necesar:
sudo zypper install -t pattern lp_sles
Activarea în sine nu instalează modelele sau pachetele; parcurgeți ambii pași înainte de a aștepta pachete de patch-uri live de pe canalele de actualizare.
Aplicați actualizări regulate de sistem. Patch-urile live pentru kernel ajung sub formă de pachete prin mecanismul de actualizare regulată. Pentru o rulare manuală a patch-urilor, utilizați același flux de lucru de întreținere aprobat ca și restul gazdei, de exemplu:
sudo zypper refresh
sudo zypper patch
Verificați planul pachetului înainte de a-l confirma, în special pe sistemele de producție. Un pachet live-patch poate actualiza corecțiile eligibile pentru kernelul care rulează fără a reporni sarcinile de lucru, dar aceeași tranzacție de actualizare poate oferi și un nou pachet de bază pentru kernel. Instalarea acelui pachet de kernel poate declanșa în continuare o recomandare de repornire. Patch-urile live sunt cumulative pentru revizia țintă a kernelului lor; acestea nu înlocuiesc întreținerea obișnuită a kernelului.
Verificați dacă este activ un patch live. După finalizarea actualizării, verificați detaliile patch-ului:
sudo klp -v patches
SUSE documentează această comandă pentru verificarea stării aplicării patch-urilor și vizualizarea CVE-urilor sau a defectelor abordate de patch-ul activ. Confirmați că patch-ul listat corespunde kernel-ului rulant înregistrat în Pasul 1. Un pachet inițial sau de tip seed live-patch poate să nu conțină remedieri; acesta pregătește revizia kernel-ului respectiv pentru patch-uri viitoare. Prezența sa în sine nu înseamnă că a fost aplicată o remediere de securitate specifică.
Depanați o stare goală sau nepotrivită. Verificați dacă există un pachet live-patch pentru kernelul care rulează și dacă sunt disponibile date despre ciclul de viață:
sudo zypper se --details 'kernel-livepatch-*'
sudo zypper lifecycle
Pentru datele ciclului de viață, SUSE precizează că lifecycle-data-sle-module-live-patchingpachetul trebuie instalat. Dacă nu există un pachet de patch-uri pentru kernelul care rulează exact, confirmați că depozitele sau canalele Live Patching corecte sunt activate și că remedierea relevantă este eligibilă pentru Live Patching. Nu deduceți o eroare dintr-o listă de patch-uri goală atunci când nu a fost lansată nicio actualizare eligibilă.
Programați repornirea necesară pentru o actualizare completă a kernelului. SUSE nu poate converti fiecare corecție într-un patch activ; unele modificări necesită înlocuirea structurilor de date ale kernelului sau nu pot fi aplicate în siguranță în timpul execuției. Păstrați actualizările normale ale kernelului în planul de întreținere și reporniți sistemul atunci când actualizarea o necesită. Evitați ascunderea notificărilor de repornire prin blocarea pe termen nelimitat a pachetelor kernelului: acest lucru amână corecțiile complete ale kernelului în loc să le aplice în mod activ.
Pentru o fereastră de întreținere fără repornire, continuați numai atunci când actualizarea conține un pachet live-patch compatibil pentru kernelul în execuție și politica de modificare o permite. Tratați o actualizare completă a pachetului de kernel ca fiind în așteptare până când gazda a pornit noul kernel.
Verificarea este reușită atunci când klp -v patchesidentifică informațiile despre live-patch-ul activ pentru kernel, afișate prin uname -r, iar corecția așteptată apare în detaliile corecției. Gazda ar trebui să rămână la aceeași versiune de kernel, deoarece nu a avut loc nicio repornire. Dacă managerul de actualizări solicită în continuare o repornire, verificați dacă a instalat un kernel de bază nou sau o corecție în afara domeniului de aplicare al Live Patching; această solicitare este o cerință de întreținere, nu ceva ce comanda de status live-patch poate anula.
Configurați calea corectă pentru Live Patching pentru SLES 16.0 sau 15 SP7, aplicați corecțiile eligibile ale kernelului și confirmați ce este activ fără a-l confunda cu o actualizare a kernelului care necesită repornire.
SLES 15 SP5 poate migra online la SP6, dar fiecare nod trebuie să repornească. Folosiți o actualizare continuă testată sau o trecere de la un sistem blue-green la altul pentru a menține accesibile sarcinile de lucru.
Creați, rafinați și verificați un profil AppArmor cu privilegii minime pe SLES 15 SP7, cu o notă clară privind setările implicite SELinux pentru SLES 16.
Folosește profilul STIG acceptat de SUSE pentru a scana SLES 15, a testa remedierea, a revizui constatările rămase și a păstra dovezile evaluării.
Urmăriți o conexiune Cockpit eșuată prin DNS, portul 9090, socketul systemd, firewalld, TLS și setările de conectare folosind instrucțiunile SUSE actuale.
Creați o conexiune Ethernet redundantă pe SLES 15 cu YaST și Wicked, configurați legătura activă de backup și verificați ambele porturi și failover-ul.
Transformați un sistem SLES 15 existent într-un profil AutoYaST revizuit, validați-l și utilizați-l pentru a implementa un server de testare cu mai puțini pași manuali.
Instalați instrumentele SLES 15 KVM și libvirt, activați serviciul gazdă corect și configurați mașinile virtuale selectate pentru a porni după o repornire.
Fă copii de rezervă ale fișierelor Nextcloud și MariaDB împreună, programează snapshot-uri Restic criptate cu cron și verifică recuperarea fără a risca serverul activ.
Exportați o cutie poștală individuală Zimbra Community Edition, validați copia de rezervă TGZ și restaurați elementele lipsă fără a suprascrie e-mailurile existente.
