È importante riavviare Linux dopo un aggiornamento del kernel?


19

Ho alcuni server web Fedora e Debian di produzione che ospitano i nostri siti e account shell utente (usati per il lavoro git vcs, alcune schermate + sessioni irssi, ecc.).

Di tanto in tanto un nuovo aggiornamento del kernel scenderà dalla pipeline in yum/ apt-get, e mi chiedevo se la maggior parte delle correzioni fosse abbastanza grave da giustificare un riavvio, o se posso applicare le correzioni senza il riavvio.

Il nostro server di sviluppo principale ha attualmente 213 giorni di uptime e non ero sicuro che non fosse sicuro eseguire un kernel così vecchio.


Dovresti davvero separare l'hosting di produzione (abbastanza esposto e critico per la sicurezza, dovresti ottenere subito gli aggiornamenti) dall'esecuzione di repository git (probabilmente solo utenti fidati ma devono essere sicuri) e sessioni di schermate generali. Le macchine virtuali sono economiche!
Poolie,

Risposte:


24

Non c'è niente di veramente speciale nell'avere un lungo periodo di attività. È generalmente meglio avere un sistema sicuro. Tutti i sistemi hanno bisogno di aggiornamenti ad un certo punto. Probabilmente stai già applicando aggiornamenti, pianifichi interruzioni quando applichi tali aggiornamenti? Probabilmente dovresti nel caso in cui qualcosa vada storto. Un riavvio non dovrebbe essere così tanto tempo davvero.

Se il tuo sistema è così sensibile alle interruzioni, probabilmente dovresti pensare a una sorta di configurazione del cluster in modo da aggiornare un singolo membro del cluster senza far cadere tutto.

Se non si è sicuri di un determinato aggiornamento, è probabilmente più sicuro pianificare un riavvio e applicarlo (preferibilmente dopo averlo testato su un altro sistema simile).

Se sei interessato a sapere se l'aggiornamento è importante, prenditi del tempo per leggere l'avviso di sicurezza e segui i collegamenti al CVE o ai post / elenchi / blog che descrivono il problema. Questo dovrebbe aiutarti a decidere se l'aggiornamento si applica direttamente al tuo caso.

Anche se non pensi che sia applicabile, dovresti comunque considerare di aggiornare il tuo sistema alla fine. La sicurezza è un approccio stratificato. Dovresti supporre che ad un certo punto quegli altri livelli potrebbero fallire. Inoltre, potresti dimenticare di avere un sistema vulnerabile perché hai saltato un aggiornamento quando modifichi la configurazione in un momento successivo.

Comunque, se si desidera ignorare o attendere qualche istante sull'aggiornamento sui sistemi basati su Debian, è possibile mettere in attesa il pacchetto. Personalmente mi piace mettere in attesa tutti i pacchetti del kernel per ogni evenienza.

Metodo CLI per impostare un blocco su un pacchetto su sistemi basati su Debian.

dpkg --get-selections | grep 'linux-image' | sed -e 's/install/hold/' | sudo dpkg --set-selections

1
Non è che dobbiamo essere sempre attivi, ma piuttosto che alcuni dei nostri utenti hanno sessioni aperte (cioè IRC) che possono essere fastidiose (dal punto di vista dell'utente) per il riavvio.
lfaraone,

12

La maggior parte degli aggiornamenti non richiede un riavvio, ma lo fanno gli aggiornamenti del kernel (non è possibile sostituire realmente il kernel in esecuzione senza riavviare).

Una cosa che ho scoperto è che se il tuo server è in esecuzione da molto tempo senza riavvio, è più probabile che tu voglia fare controlli del disco (fsck) quando riavvii, e questo può aumentare significativamente il tempo necessario per tornare indietro di nuovo funzionante. Meglio anticiparlo e pianificarlo.

Ho anche scoperto che a volte le modifiche alla configurazione possono perdersi e non verranno notate fino al riavvio (come l'aggiunta di nuovi indirizzi IP / regole di iptables, ecc.) Ciò aumenta anche il "rischio di downtime" quando si riavvia di rado.

È preferibile pianificare un periodo di inattività durante il riavvio, oppure, se questa non è un'opzione desiderabile, impostare i server in cluster in modo che i riavvii possano essere eseguiti, se necessario.


8

Se hai solo bisogno di aggiornamenti di sicurezza e non di un kernel completamente nuovo, potresti essere interessato a Ksplice : ti consente di patchare alcuni aggiornamenti del kernel in un kernel in esecuzione.


Solo Oracle Linux: |
rogerdpack,

3

Non esiste una risposta semplice a questo, alcuni aggiornamenti del kernel non sono realmente legati alla sicurezza e alcuni potrebbero risolvere problemi di sicurezza che non ti riguardano, mentre altri potrebbero interessarti.

Il miglior approccio imo è quello di iscriversi alle relative mailing list di sicurezza come l'annuncio di sicurezza di Ubuntu in modo da poter vedere quando escono le patch di sicurezza e come potrebbero influenzarti.

Vorrei anche prendere in considerazione apticron o simili per ottenere i dettagli e le modifiche di eventuali altri aggiornamenti del pacchetto.


2

Questa è una funzione dell'aggiornamento - se corregge un priv. escalation che comporta l'accesso alla radice, quindi è possibile applicarlo.


2

Nel caso in cui non si riavvii, è necessario assicurarsi che il nuovo kernel non sia quello predefinito da avviare all'avvio.

L'ultima cosa che vuoi è un kernel non testato utilizzato per la produzione dopo un riavvio non pianificato.


1

Come menzionato mibus, se si installa il kernel e non si riavvia, assicurarsi che non sia quello predefinito. Non sai se o in quale stato tornerà il tuo server, quindi assicurati che sia testato.

Detto questo, penso che sia bene prendere l'abitudine di riavviare le macchine su base abbastanza regolare quando possibile. Molti errori hardware e software si manifestano solo al riavvio ed è meglio scoprirli quando si pianifica un riavvio anziché durante un'interruzione non pianificata.


0

Nota che alcuni degli aggiornamenti del kernel debian richiedono (bene, altamente raccomandato) di riavviare al più presto dopo averli applicati.

Questo è il caso in cui la differenza non è sufficiente per giustificare una modifica della directory dei moduli, ma i moduli possono differire.

Sarai avvisato da Debian quando installi tali pacchetti del kernel.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.