Un aggiornamento del kernel SLES potrebbe comunque mostrare "riavvio necessario" anche dopo l'attivazione di Live Patching. Ciò non significa automaticamente che l'installazione sia fallita: le patch live coprono solo le correzioni che SUSE può distribuire in sicurezza per il kernel attualmente in esecuzione, mentre un kernel sostitutivo o correzioni che non possono essere applicate tramite Live Patching richiedono comunque un riavvio. La guida di SUSE per SLES 16.0 Kernel Live Patching, pubblicata l'8 ottobre 2026, fornisce una procedura di installazione più recente: installare il kernel_livepatchingpattern nell'ambito dell'abbonamento SLES standard. SLES 15 SP7 utilizza un'estensione Live Patching e un lp_slespattern separati.
Utilizza la procedura specifica per la tua versione, applica gli aggiornamenti tramite il normale flusso di lavoro dei pacchetti SUSE e verifica la patch attiva con klp -v patches. Questi passaggi presuppongono un host SLES registrato con accesso ai repository di aggiornamento supportati.
Identifica la release e il kernel in esecuzione. Esegui:
cat /etc/os-release
uname -r
uname -m
Annotare la versione di SLES, la versione del kernel e l'architettura. I pacchetti di patch live corrispondono a una specifica revisione del kernel, quindi un pacchetto per un kernel diverso in esecuzione non dimostra che il kernel attivo sia stato patchato. I comandi seguenti utilizzano le istruzioni correnti di SLES 16.0 e SLES 15 SP7; non copiare un modello o un percorso di attivazione specifico di una release in una versione diversa.
Su SLES 16.0, installa il pattern incluso. La guida attuale di SUSE afferma che Kernel Live Patching è incluso nell'abbonamento SLES standard. Installa il relativo pattern:
sudo zypper install -t pattern kernel_livepatching
Se i repository contengono una patch live idonea per il kernel installato, il gestore di pacchetti la seleziona durante l'installazione; SUSE documenta che il kernel viene aggiornato tramite Live Patching come parte di questo processo. Non è richiesto alcun codice di registrazione aggiuntivo per il Live Patching in questa procedura SLES 16.0.
Su SLES 15 SP7, attivare prima l'estensione. Questa versione richiede abbonamenti SLES e SLES Live Patching attivi. Elencare le estensioni disponibili e utilizzare il comando di attivazione specifico per l'architettura visualizzato:
sudo SUSEConnect --list-extensions
sudo SUSEConnect -p sle-module-live-patching/15.7/x86_64 -r LIVE_PATCHING_REGISTRATION_CODE
Il secondo comando è un esempio per architettura x86_64. Sostituiscilo con il percorso esatto del prodotto mostrato nel tuo --list-extensionsoutput e fornisci il codice di registrazione Live Patching valido. Quindi installa il pattern richiesto:
sudo zypper install -t pattern lp_sles
La sola attivazione non installa i pattern o i pacchetti; completa entrambi i passaggi prima di poter ricevere i pacchetti di patch ufficiali dai canali di aggiornamento.
Applicare regolarmente gli aggiornamenti di sistema. Le patch live del kernel vengono distribuite come pacchetti tramite il meccanismo di aggiornamento periodico. Per l'applicazione manuale di una patch, utilizzare lo stesso flusso di lavoro di manutenzione approvato per il resto del sistema host, ad esempio:
sudo zypper refresh
sudo zypper patch
Prima di confermare l'installazione, è importante esaminare attentamente il piano di installazione, soprattutto sui sistemi di produzione. Un pacchetto di patch live può aggiornare le correzioni idonee per il kernel in esecuzione senza riavviare i carichi di lavoro, ma la stessa transazione di aggiornamento può anche offrire un nuovo pacchetto kernel di base. L'installazione di tale pacchetto kernel potrebbe comunque richiedere un riavvio. Le patch live sono cumulative per la revisione del kernel di destinazione e non sostituiscono la normale manutenzione del kernel.
Verifica se è attiva una patch live. Al termine dell'aggiornamento, controlla i dettagli della patch:
sudo klp -v patches
SUSE documenta questo comando per verificare lo stato delle patch e visualizzare i CVE o i difetti risolti dalla patch live attiva. Confermare che la patch elencata corrisponda al kernel in esecuzione registrato nel passaggio 1. Un pacchetto live-patch iniziale o seed potrebbe non contenere correzioni; serve a preparare quella revisione del kernel per le patch future. La sua sola presenza non significa che sia stata applicata una specifica correzione di sicurezza.
Risolvere i problemi relativi a uno stato vuoto o non corrispondente. Verificare se esiste un pacchetto di patch live per il kernel in esecuzione e se sono disponibili i dati del ciclo di vita:
sudo zypper se --details 'kernel-livepatch-*'
sudo zypper lifecycle
Per quanto riguarda le date del ciclo di vita, SUSE afferma che il lifecycle-data-sle-module-live-patchingpacchetto deve essere installato. Se non esiste un pacchetto di patch per il kernel in esecuzione, verificare che i repository o i canali di Live Patching corretti siano abilitati e che la correzione pertinente sia idonea per l'applicazione in tempo reale. Non dedurre un errore da un elenco di patch vuoto quando non è stato rilasciato alcun aggiornamento idoneo.
Pianifica il riavvio necessario per un aggiornamento completo del kernel. SUSE non può convertire ogni correzione in una patch attiva; alcune modifiche richiedono la sostituzione delle strutture dati del kernel o non possono essere applicate in modo sicuro in fase di esecuzione. Mantieni i normali aggiornamenti del kernel nel tuo piano di manutenzione e riavvia il sistema quando l'aggiornamento lo richiede. Evita di nascondere gli avvisi di riavvio bloccando indefinitamente i pacchetti del kernel: in questo modo si rimandano le correzioni complete del kernel anziché applicarle in tempo reale.
Per una finestra di manutenzione senza riavvio, procedere solo se l'aggiornamento contiene un pacchetto live-patch compatibile con il kernel in esecuzione e la policy di modifica lo consente. Considerare un aggiornamento completo del pacchetto del kernel come in sospeso finché l'host non ha avviato il nuovo kernel.
Il controllo ha esito positivo quando klp -v patchesvengono identificate le informazioni di live-patch attive per il kernel mostrato da uname -re la correzione prevista appare nei dettagli della patch. L'host dovrebbe rimanere sulla stessa versione del kernel in esecuzione poiché non si è verificato alcun riavvio. Se il gestore degli aggiornamenti richiede comunque un riavvio, verificare se ha installato un nuovo kernel di base o una correzione al di fuori dell'ambito di Live Patching; tale richiesta è un requisito di manutenzione, non qualcosa che il comando live-patch status può annullare.
Configura il percorso Live Patching corretto per SLES 16.0 o 15 SP7, applica le correzioni del kernel idonee e verifica quali sono attive senza confonderle con un aggiornamento del kernel che richiede il riavvio.
SLES 15 SP5 può essere migrato online a SP6, ma ogni nodo deve essere riavviato. Utilizzare un aggiornamento progressivo testato o un passaggio di consegne blue-green per mantenere i carichi di lavoro raggiungibili.
Creare, perfezionare e verificare un profilo AppArmor con privilegi minimi su SLES 15 SP7, con una nota chiara sull'impostazione predefinita di SELinux in SLES 16.
Utilizza il profilo STIG supportato da SUSE per analizzare SLES 15, testare le soluzioni, rivedere i risultati rimanenti e conservare le prove di valutazione.
Tracciare una connessione Cockpit non riuscita attraverso DNS, porta 9090, socket systemd, firewalld, TLS e impostazioni di accesso, seguendo le linee guida SUSE aggiornate.
Crea una connessione Ethernet ridondante su SLES 15 con YaST e Wicked, configura il bonding attivo-backup e verifica entrambe le porte e il failover.
Trasforma un sistema SLES 15 esistente in un profilo AutoYaST verificato, convalidalo e utilizzalo per implementare un server di test con un numero ridotto di passaggi manuali.
Installa gli strumenti KVM e libvirt di SLES 15, abilita il servizio host corretto e configura le macchine virtuali selezionate per l'avvio automatico dopo un riavvio.
Utilizza i processi systemd e il registro di avvio precedente per individuare un servizio, un punto di montaggio o una dipendenza di archiviazione che rallenta il sistema, quindi correggi il problema senza mascherarne la causa.
Utilizza firewall-cmd per ispezionare la zona attiva, consentire HTTP in modo sicuro, preservare l'accesso SSH e verificare che la regola sopravviva a un riavvio su SLES 15.
