Quanto spesso devo aggiornare il nostro server Linux?

Sono responsabile della gestione sia del nostro server di produzione (posta, web, database in un unico server) sia del nostro server di prova. Entrambi sono basati su Debian. Tuttavia, dato che sono molto nuovo nell'amministrazione del sistema, ho installato solo gli aggiornamenti mentre mi imbatto in cose che devono essere aggiornate in modo da poter avere nuove funzionalità e ottenere correzioni di bug. È un processo abbastanza ad hoc in questo momento, e mi piacerebbe renderlo meno.

Quindi mi chiedo come le persone che sanno cosa stanno facendo gestiscono questo? Con quale frequenza esegui gli aggiornamenti sui tuoi server? Il processo di aggiornamento è diverso tra test e produzione? Prima aggiorni sempre qualche server di prova? E fai un aggiornamento completo di tutto il software o installi solo gli aggiornamenti selezionati?

Corro apt-get update -qq; apt-get upgrade -duyq ogni giorno. Questo verificherà la presenza di aggiornamenti, ma non li farà automaticamente.

Quindi posso eseguire manualmente gli aggiornamenti mentre sto guardando e posso correggere tutto ciò che potrebbe andare storto.

Oltre alle preoccupazioni di sicurezza nel mantenere un sistema con patch, trovo che se lo lascio troppo a lungo tra le patch, finisco con un sacco di pacchetti che vogliono essere aggiornati, e questo mi spaventa molto di più del semplice aggiornamento di uno o due ogni settimana o giù di lì. Pertanto tendo a eseguire i miei aggiornamenti settimanalmente o, se sono prioritari, tutti i giorni. Questo ha l'ulteriore vantaggio di sapere quale pacchetto ha rotto il tuo sistema (cioè se stai aggiornando solo un paio alla volta)

Prima aggiorno sempre i sistemi meno critici. Ho anche un "piano di rollback" in atto nel caso in cui non riesco a riparare il sistema. (poiché la maggior parte dei nostri server sono virtuali, questo piano di rollback di solito consiste nello scattare un'istantanea prima dell'aggiornamento a cui posso ripristinare se necessario)

Detto questo, penso che un aggiornamento abbia rotto qualcosa solo una o due volte negli ultimi 4 anni e che fosse su un sistema altamente personalizzato, quindi non devi essere TROPPO paranoico :)

Oltre alle risposte precedenti, un paio in particolare di cose Debian: dovresti iscriverti a debian-security-annuncio e debian-annuncio e / o controllare la pagina di sicurezza Debian .

Supponendo che si stia eseguendo la versione stabile di Debian, la maggior parte delle patch sarà legata alla sicurezza o ai bug, il che dovrebbe significare che non ci saranno troppe modifiche importanti tra le versioni di un determinato pacchetto. Secondo la politica delle patch debian, le patch avrebbero dovuto essere in fase di test da qualche tempo prima di essere spostate nel ramo stabile dal manutentore. Ovviamente questo non fermerà le rotture durante l'applicazione di patch ma dovrebbe prevenirle nella maggior parte dei casi.

Sarebbe prudente assicurarsi che il server di test sia tenuto aggiornato e che tutti i pacchetti che presentano bug che riguardano te e i tuoi server siano tenuti aggiornati. Tutti i pacchetti che dispongono di avvisi di sicurezza nei loro confronti devono essere aggiornati non appena si conosce che la patch è stabile.

Debian è di solito un sistema operativo molto stabile e non uno di cui dovresti preoccuparti eccessivamente delle rotture, ma leggi sempre cosa verrà aggiornato prima che venga aggiornato e tieni d'occhio tutto ciò che sembra strano. Uso VCS anche sul mio / etc / dir per assicurarmi che tutte le modifiche al file di configurazione possano essere visualizzate con un comando 'git diff'.

Faccio una corsa a secco (prima) per vedere cosa verrà aggiornato. A volte, le librerie (chiamiamolo libfoo per questo esempio) cambiano la loro API, che rompe i programmi che abbiamo scritto / installato noi stessi. Se qualche libreria critica viene aggiornata, afferro la fonte e provo a ricostruire le nostre cose contro di essa prima dell'aggiornamento.

Controllo anche che non stiamo passando a una versione intermedia di alcuni servizi pubblici, ad esempio apache, ecc. Preferirei rimanere un anno indietro e non riscontrare rotture casuali, a meno che l'aggiornamento non sia critico.

Se sei un amministratore di sistema, dovresti estrarre i feed RSS da siti come Secunia , che dovrebbe informarti in anticipo se la tua distribuzione invierà alcune patch.

Mai e poi mai ciecamente aggiornare / aggiornare. Sfortunatamente, il compito di conoscere ciò che è rotto ricade su di te, non sul gestore dei pacchetti di distribuzione, specialmente se i tuoi sistemi supportano i programmatori.

Dove lavoro, abbiamo un processo piuttosto esteso che prevede l'utilizzo di un software chiamato PatchLink per avvisarci degli aggiornamenti più importanti relativi alla sicurezza e li applichiamo dopo il test, pacchetto per pacchetto. Abbiamo migliaia di server però.

Se hai solo due server, il processo dovrebbe essere molto più semplice. Anche se non credo che fare un "apt-get update / upgrade" sia la soluzione migliore.

Vorrei monitorare le patch per il software in esecuzione e prendere decisioni in base alle correzioni in quelle versioni su quando eseguire l'aggiornamento.

Dato che hai un server di prova, ovviamente, testa sempre l'aggiornamento prima di applicarli.

Gli aggiornamenti manuali sono i migliori come indicato qui, nel senso che puoi vedere cosa sta succedendo. Tuttavia, per un numero molto elevato di server che potrebbero diventare poco pratici. La corsa a secco è una pratica standard, infatti, la maggior parte dei gestori di pacchetti ti chiederà prima di procedere.

Aggiornare regolarmente tende ad essere il migliore anche se può essere un po 'un atto di bilanciamento. Aggiornamenti frequenti significano meno in una volta sola e meno errori in una sola volta. Se le cose vanno male ci sono meno candidati da controllare. I pacchetti sono anche leggermente migliori nell'aggiornamento in passaggi più piccoli, come in genere quando gli aggiornamenti del programmatore stanno guardando dall'ultima versione alla successiva, se possono prestare attenzione oltre l'ultima versione può variare, anche se questo tende a importare principalmente per software in rapida evoluzione.

Non tutti gli aggiornamenti sono senza interruzioni. Ti consigliamo di fare attenzione a questo. Alcuni riavvieranno i servizi portando a tempi di inattività.

In una configurazione ideale potresti avere quanto segue:

• Un mezzo per cambiare apparentemente i server (A / B o tick tock). Ciò significa che ne aggiorni uno mentre è in panchina, quindi scambia semplicemente il traffico da quello corrente a quello nuovo. Questo può essere più complicato per servizi come database.
• La possibilità di testare gli aggiornamenti. Dovresti avere server di prova che sono praticamente cloni di produzione (ma senza connessione a nessun servizio di produzione). Ciò consentirebbe di testare prima gli aggiornamenti.
• Una buona strategia di backup, incrementale è l'ideale. Non si sa mai. È sempre meglio prevenire che curare.
• Essere consapevoli di quali tempi hanno più attività e quale livello di downtime è tollerabile.
• Sapere come ripristinare un aggiornamento o un pacchetto specifico.
• Avere i propri mirror dei pacchetti in modo che gli aggiornamenti siano coerenti e prevedibili tra server. Questo è il primo passo verso un discreto sistema incustodito di cui ti puoi fidare. Ciò significa che è possibile aggiornare il mirror, eseguire l'aggiornamento su una o più macchine di prova, quindi, se va bene, lasciarlo uscire automaticamente. Mi sono divertito molto con la gestione appropriata di circa 800 macchine EPOS.
• Un buon livello di coerenza in modo che tu possa sapere che se qualcosa funzionerà qui, funzionerà lì.

Alcuni di questi possono essere eccessivi a vari livelli per piccoli setup ma dovrebbero essere tenuti a mente.

In generale, gli aggiornamenti sono in genere relativamente indolori per le distro dei server. Questo perché quasi sempre si attaccano solo alle correzioni di bug e agli aggiornamenti di sicurezza. Tuttavia, potresti avere problemi se le persone hanno fatto cose strane nel sistema o hai aggiunto ulteriori fonti di pacchetti.

Sebbene sia moderatamente raro, occasionalmente commettono errori e interrompono la compatibilità tra le versioni minori del pacchetto.

Mi piace cron-apt per automatizzare questo processo, ma come ha sottolineato @dinomite su un'altra domanda relativa agli aggiornamenti, configurarlo in modo specifico per automatizzare gli aggiornamenti relativi alla sicurezza è un'idea molto intelligente: puoi quindi aggiornare manualmente ciò di cui hai bisogno. Avevo usato cron-apt per tutti gli aggiornamenti, ma in realtà l'ho modificato in base alla sua risposta. Se ti piace, dovresti probabilmente votare la sua risposta piuttosto che questa.

Su debian installo cron-apt e modifico il suo file di configurazione per inviarmi eventuali modifiche. in questo modo ricevo una notifica se ci sono aggiornamenti per i miei sistemi e faccio gli aggiornamenti a mano

Sulla stessa linea di cron-apt, dovresti dare un'occhiata al pacchetto di aggiornamenti automatici http://packages.debian.org/lenny/unattended-upgrades .

È molto facile da configurare e ti permetterà di scaricare e applicare automaticamente gli aggiornamenti di sicurezza, ma lascia altri aggiornamenti per l'aggiornamento manuale (o a tua discrezione aggiorna tutto!).

La Guida ufficiale del server Ubuntu, ha una sezione ragionevolmente dettagliata che copre l'uso del pacchetto di aggiornamenti automatici https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html

Nota: a seconda del livello di attenzione / paranoia è possibile eseguire prima un aggiornamento progressivo su un gruppo di server di prova, quindi se non ci sono problemi, consentire l'aggiornamento delle caselle di produzione, anche se personalmente non ho riscontrato alcun problema con gli aggiornamenti di sicurezza distruggere il caos finora (bussare al legno) ...

Esiste anche un'opzione di configurazione per inviare via e-mail i risultati di ogni aggiornamento di sicurezza, una volta applicato. Inoltre, se durante l'aggiornamento sono state presentate finestre di dialogo o prompt interattivi, che richiedono una modifica manuale da parte di un amministratore di sistema, verranno menzionati anche questi.

Disattivo personalmente gli aggiornamenti automatici e non eseguo regolarmente alcun tipo di aggiornamento dei pacchetti sui server nei miei ambienti, a meno che: (a) vi sia un avviso CERT importante per uno dei pacchetti sul mio sistema; (b) ho bisogno di aggiornare i singoli pacchetti per motivi specifici; (c) OS o pacchetti stanno raggiungendo la fine del ciclo, non saranno più supportati e dobbiamo continuare ad avere supporto. Il mio ragionamento è che l'aggiornamento senza sapere cosa viene cambiato o perché lascia troppo spazio per qualcosa di rotto. Faccio cose del genere da 14 anni e funziona bene.

Oltre alle cose che è menzionato, dovresti usare una sorta di strumento di monitoraggio (Nagios o qualunque cosa galleggi la tua barca) per avvisarti degli aggiornamenti.

Per quanto spesso accade: non appena è disponibile un aggiornamento!