Gestire gli aggiornamenti su centinaia di server Debian

Quali pensi siano le migliori pratiche per mantenere aggiornate dozzine (se non centinaia) di server debian? Tenendo presente che:

• Esistono gruppi di server (ovvero server Web identici, server DB, ...)
• Possono esserci diversi problemi di Debian (lenny, etch)
• Eseguire un ciclo su tutti i server e fare apt-get update && upgrade non è accettabile (perché è quello che sto facendo al momento :)) Dovrebbe essere meglio di così!

Attualmente, quando finalmente finisco tutti gli aggiornamenti, viene pubblicato un nuovo aggiornamento per la sicurezza e devo ricominciare da capo.

Grazie in anticipo alla community serverfault!

Uso apt-dater per gestire l'aggiornamento di tutti i miei box Debian. Sembra fare abbastanza bene il trucco. Tuttavia, non ho provato a ridimensionarlo a centinaia di host.

Google ha risolto questo con debmarshal:

http://code.google.com/p/debmarshal/

Ciò consente di approvare i pacchetti da un repository upstream per l'installazione sugli host di produzione.

Quindi puoi semplicemente eseguire cron-apt in modalità completamente automatica.

Ecco un video introduttivo:

http://www.youtube.com/watch?v=L3hRToC23mQ

Stavamo provando con Puppet per aggiornare le correzioni di sicurezza su pacchetti non essenziali. Avremmo eseguito apticron per inviare tramite e-mail un elenco di aggiornamenti per ogni server, quindi ogni giorno avremmo eseguito uno script che univa questi aggiornamenti in un file manifest fantoccio che forniva il pacchetto e la versione per ogni distribuzione. Ciò aggiornerebbe quindi un mucchio di file sui singoli server e darebbe il via a uno script di aggiornamento quando un pacchetto doveva essere aggiornato. Questo ha funzionato abbastanza bene, ma non l'abbiamo testato tanto quanto vorrei. Questo schema ha aggirato la limitazione di Puppet di non avere la stessa risorsa definita in più punti.

Inoltre, non mi sentivo a mio agio con gli aggiornamenti automatici di cose come MySQL o PostgreSQL, in cui un aggiornamento casuale avrebbe chiuso un servizio, probabilmente nel bel mezzo della giornata. Questi richiederebbero comunque aggiornamenti manuali.

Spacewalk e Debmarshall sembrano alternative adatte al nostro schema di marionette.

Apparentemente, Spacewalk ora ha il supporto preliminare per Debian. Questo, insieme, forse, con Puppet, sarebbe il mio punto di partenza. Sono abbastanza sicuro che il ragazzo che sta sviluppando il supporto Debian per Spacewalk ti adorerà per aver collaborato con lui nel portare il supporto Debian a un livello superiore.

Nel modo dei sistemi di configurazione basati su pull come Puppet, ci sono anche bcfg2 e cfengine. L'uno o l'altro di questi potrebbe soddisfare bene le tue esigenze. Sto implementando bcfg2 nel mio laboratorio in questo momento.

Una soluzione può essere data da func

Non sono sicuro del tipo di soluzione che ti aspetti. Probabilmente conosci cron job, ma non aggiornerei i sistemi alla cieca in quanto sono necessari interventi umani (ed è per questo che ti pagano per fare questo, giusto?)

Se avessi sistemi completamente identici, potresti prendere in considerazione l'utilizzo di qualcosa come rsync per introdurre le differenze, ma capire quali file non rsync potrebbe essere difficile e non lo farei mentre i servizi sono in esecuzione. Almeno gli script di aggiornamento sono impostati per gestire il riavvio dei servizi e l'unione delle differenze nei file di configurazione.

Forse se spieghi qual è il problema con l'esecuzione dei comandi apt-get, potremmo vedere cosa vuoi evitare.

Se il problema è la larghezza di banda e il tempo per il download, forse dovresti impostare una casella per agire come repository Debian locale. Ci sono guide Debian su come farlo.

Ecco alcuni suggerimenti su come ridurre al minimo il numero di cose che è necessario aggiornare.

Quando installi Debian, non installare Desktop a meno che tu non abbia davvero bisogno di usare X su quella console. La maggior parte dei server non necessita dell'installazione di X. Ciò può ridurre in modo significativo il numero di pacchetti sul sistema e quindi non è necessario aggiornare tanti pacchetti.

Verifica che il sources.list includa solo i repository di cui hai veramente bisogno. Se avessi sperimentato alcuni repository e te ne fossi dimenticato, potresti apportare aggiornamenti che non ti servono o che non desideri.

In caso di problemi con l'esecuzione cieca di aggiornamenti su un server di produzione, fare attenzione a consultare le guide di aggiornamento di Debian in caso di aggiornamenti importanti (da 4.0 a 5.0). Questi andranno molto bene se segui le istruzioni per l'aggiornamento. Non è facile come eseguire apt-get dist-upgrade e andarsene. A volte nelle istruzioni ci sono anche indicazioni su quando eseguire aptitude anziché apt-get - ci sono piccole differenze in essi.

Ora questo strumento "guscio di ballerino"? Mi piace e lo uso. Ma non so se puoi usarlo per così tanti host. Forse potresti provare ...

http://www.netfort.gr.jp/~dancer/software/dsh.html.en

Ed è nel repository.

Clusterssh. Accedi a tutti i server e dai loro gli stessi esatti comandi, così puoi anche reagire alle finestre di dialogo. Se un server riceve una domanda aggiuntiva, fai semplicemente clic su quello e sarà l'unico a rispondere.

L'ho usato per aggiornare 25 server web da etch a lenny. Ha funzionato come un fascino.

http://sourceforge.net/projects/clusterssh/

Cluster ssh è un buon suggerimento.

debmarshal non fa ancora parte di debian - non sono nemmeno sicuro che sarà un pacchetto - sembra essere un sistema completamente diverso con un repository specializzato. Come ha affermato l'oratore, questo è attualmente ostile all'utente, non facile da usare.

Spacewalk sembra essere un clone di Redhat Network, almeno nell'interfaccia web. Ho avuto risultati negativi dall'uso di Redhat Network per aggiornare i sistemi. Una volta è stato sospeso, senza motivo apparente, e ha causato l'interruzione del servizio. Ho fatto un aggiornamento yum subito dopo e ha funzionato così bene, quindi posso solo supporre che il problema provenisse da qualcosa che ha funzionato dal lato RHN. L'altra cosa che non mi piace degli aggiornamenti di RHN è che non sai quando accadrà l'aggiornamento, per cercare i problemi.