Per aggiornare? O no?

per favore perdona questa domanda piuttosto semplice.

Prima di tutto, non sono un amministratore di sistema e la mia esperienza con Linux è piuttosto limitata.

Circa 3-4 mesi fa, ho installato un server CentOS in funzione, per una serie di motivi. Lo stiamo usando come server di sviluppo per siti Web (a cui i nostri clienti hanno accesso), server di sovversione, e stiamo ospitando un wiki anche lì per la comunicazione interna, quindi è diventato uno strumento abbastanza importante per noi. (Probabilmente più importante di quanto pensassimo fosse quando l'ho installato!)

Mi è venuto in mente che Yum vuole aggiornare circa 250 pacchetti alle ultime versioni del repository.

Dato che il server funziona bene per noi, dovrei correre il rischio di aggiornare questi pacchetti? I rischi per la sicurezza superano il rischio di rottura del server quando aggiorno tutto?

Dovrei sottolineare che mentre ho i backup di tutto, ci vorrebbe tempo per sistemare le cose come sono adesso, e al momento non ho molto tempo libero al lavoro!

Se il consiglio è di aggiornare, ci sono delle migliori pratiche che potrebbero essere trasmesse per rendere il processo il più sicuro possibile?

Grazie in anticipo per qualsiasi consiglio.

AGGIORNAMENTO - Grazie per le risposte a tutti. Se avessi abbastanza rappresentante per votare tutti, lo farei. ;) Ho deciso di fantasma del disco rigido e aggiornamento. Sfortunatamente, ottenere un amministratore di sistema a tempo pieno o part-time al momento non è un'opzione, quindi dovrò affrontare il problema nel miglior modo possibile!

Soluzione rapida e sporca (ad es. Battlefield Administrator):

1. Porta il tuo sistema offline (spero che tu possa farlo) e fai un backup NortonGhost (o qualcosa di simile) su un secondo disco rigido.

2. Avviare il 2 ° disco rigido (per assicurarsi che il backup funzioni effettivamente) ed eseguire l'aggiornamento yum su QUELLA unità.

3. Se tutto funziona ... complimenti!

4. Se rovina qualcosa ... vai avanti e inserisci il tuo disco ORIGINALE e crea un "Piano B".

AGGIORNARE:

Ho pensato di menzionare che il vero problema qui è "Aggiornamento il mio sistema waaaay obsoleto e rischio di rovinarlo?" o "Lascio il mio sistema di lavoro perfettamente funzionante senza patch e rischio di farlo hackerare / compromesso?"

La risposta è ... una volta che il tuo sistema è stato patchato tramite i passaggi precedenti ... prova a rimanere sopra di esso eseguendo il backup frequentemente e patchalo frequentemente.

Quindi avrai il meglio di entrambi i mondi. ;-)

Sì, aggiorna.

RHEL (e quindi CentOS) stanno attenti a non aggiornare le versioni a qualcosa di incompatibile, invece supportano correzioni di bug e correzioni di sicurezza, quindi le modifiche effettive ai pacchetti sono minime e ragionevolmente improbabili che causino problemi di compatibilità.

Se qualche file di configurazione è cambiato, i pacchetti ti diranno di un file .rpmorig o .rpmnew che viene creato. Dipende dalla configurazione dell'RPM stesso. Puoi cercare avvisi su uno qualsiasi di quelli creati e ripristinare la tua vecchia configurazione (" cp foo foo.bak; cp foo.rpmorig foo") o guardare i file .rpmnew e incorporare eventuali modifiche nella tua configurazione.

Il problema è meno evidente se si aggiorna regolarmente.

Abbiamo molti sistemi che vengono aggiornati trimestralmente (ogni 3 mesi); e molto raramente vedono problemi dagli aggiornamenti del pacchetto. (tranne che sui sistemi che fanno cose strane nel kernel per accedere ai LUN da una SAN)

Mentre sì, ci vorrebbe tempo per l'aggiornamento, e nello stesso maniero, ci vorrebbe tempo per ripristinare se qualcosa fosse andato storto, quanto dolore / sofferenza sarebbe se i dati su quel sistema fossero eliminati attraverso un exploit / hack?

Per la maggior parte gli aggiornamenti dai repository di base CentOS sono sicuri da installare, l'unica volta che ho avuto problemi di aggiornamento con CentOS è quando avvio / o ho bisogno di utilizzare un repository esterno (DAG, RPMForge, Ect ect ..)

La migliore configurazione per questo tipo di cose è avere un server hot-swap pronto, in modo da poter testare gli aggiornamenti su di esso prima di distribuirli sul server live.

Sembra che tu abbia bisogno di un vero amministratore di sistema che impiega un paio d'ore per esaminare il tuo sistema, aggiornarlo e assicurarti che tutto funzioni di nuovo. Idealmente, questa persona dovrebbe venire e farlo per te alcune volte al mese. Un server non è una cosa da installare una volta e dimenticarsene; ha bisogno di un servizio regolare.

Se questo sistema è così importante, gli aggiornamenti di sicurezza diventano ancora più importanti. Considera le implicazioni se quel sistema deve essere rimosso per una ricostruzione se (quando?) Un pacchetto obsoleto consente un compromesso del sistema. Idealmente, avresti un server di prova configurato in modo simile che potresti aggiornare prima e controllare se qualcosa non funziona.

Quando si applicano gli aggiornamenti, è necessario assicurarsi di alcune cose:

1. Il tempo di aggiornamento è pubblicizzato a tutti coloro che utilizzano il sistema
2. Hai un piano su come aggiornare e testare ciascuna applicazione
3. Hai un piano su come annullare gli aggiornamenti se (quando?) L'aggiornamento interrompe l'app
4. E gli attuali backup esistono nel caso in cui qualcosa vada davvero storto

Un buon amministratore di sistema avrebbe esperienza in questo tipo di lavoro e dovrebbe comunque fare tutte queste cose. Se la tua organizzazione ne ha, allora potrebbe essere il momento di scaricare l'amministrazione del sistema su di essi. O se sei nervoso di farlo da solo, allora cerca di assumere qualcuno con contratto per fare questo tipo di manutenzione ordinaria. Ad ogni modo, gli aggiornamenti devono avvenire, poiché ti stai aprendo a una situazione molto peggiore lungo la linea.

Questo è il motivo per cui oggi non eseguo quasi mai sistemi di produzione su hardware reale. Li eseguo in macchine virtuali. Quindi durante un breve periodo di inattività (5 minuti), eseguo un'istantanea dall'interno di ESX stesso, o se sto usando un'installazione Xen / Solaris / OpenVZ personalizzata, faccio un'istantanea LVM dell'immagine del server. Quindi avvio il backup originale e ora ho una copia che posso fare a mio piacimento.

Detto questo, inizia con l'aggiornamento del kernel e di apache, quindi procedi all'indietro da lì. Non devi prendere l'elenco completo dei pacchetti che yum riporta, ma i vettori di attacco principali dovrebbero essere quelli che correggi il prima possibile.

Ogni volta che ho mai avuto un sistema Linux hackerato, è perché ho lasciato apache, openssh o il kernel stesso senza patch.

Vorrei solo aggiornare i pacchetti relativi alla sicurezza.

Ho avuto quella cosa esatta circa un anno fa ... Ho fatto l'aggiornamento yum sulla scatola CentOS, in esecuzione su hardware Dell e installato un kernel che non si avviava. La scatola non aveva ancora caricato nulla (altrimenti sarei stato più cauto). Abbiamo passato un sacco di tempo a scherzare con esso e sembra che ci sia qualche incompatibilità tra i kernel più recenti di CentOS / Linux e quella scatola Dell. Sii molto cauto con i tuoi aggiornamenti. Consiglio ancora l'aggiornamento poiché è la cosa giusta da fare, ma preparati a recuperare da un sistema cestinato!