Risposte:
Sui sistemi basati su Linux / Debian, cron-apt è uno strumento molto utile che può gestire l'automazione di apt tramite cron.
Lo sto usando apt-get updateogni giorno e mi mando un'e-mail se è necessario installare nuovi aggiornamenti.
Ecco una breve e ben fatta introduzione su quello strumento .
Per quanto riguarda la tua terza domanda: gestisco sempre un repository locale. Anche se è solo per una macchina, consente di risparmiare tempo nel caso in cui ho bisogno di reinstallare (generalmente uso qualcosa come aptitude autoclean), e per due macchine, quasi sempre paga.
Per i cluster che gestisco, generalmente non conservo log espliciti: lascio che il gestore pacchetti lo faccia per me. Tuttavia, per quelle macchine (al contrario dei desktop), non uso installazioni automatiche, quindi ho le mie note su ciò che intendevo installare su tutte le macchine.
Uso apt-history per la storia. Non ho idea del perché questo utile strumento non sia incluso per impostazione predefinita, è il primo pacchetto che distribuisco con Puppet .
Corro / usr / bin / apt-get update -qq; / usr / bin / apt-get dist-upgrade -duyq come cron job ogni notte. Al mattino ricevo una notifica di quali pacchetti devono essere aggiornati e i file sono già stati scaricati sulla macchina.
Quindi di solito faccio un'istantanea della macchina (la maggior parte dei nostri server sono virtuali), eseguo un apt-get dist-upgrade , controllo i nagios e mi assicuro che tutto funzioni ancora, e rimuovo l'istantanea.
Infine, tengo un elenco di tutte le modifiche apportate a tutti i server su un wiki , al fine di tenere traccia di eventuali problemi che si presentano in seguito.
Per quanto riguarda la limitazione dei download ridondanti, sono consapevole che è possibile impostare un proxy Web di memorizzazione nella cache (calamari?) Tra i server e Internet che memorizzerà nella cache i file .deb al primo accesso. Forse questo è più semplice della creazione di un repository di pacchetti locale - e ha l'ulteriore vantaggio di velocizzare la navigazione web generale.
apt-cacher è utile per i pacchetti di memorizzazione nella cache, memorizzerà nella cache la prima volta che è necessario anziché completare un mirror completo dell'intero repository risparmiando così il disco e la larghezza di banda. È anche utile poiché trasmette la prima richiesta di un pacchetto direttamente al richiedente mentre lo memorizza nella cache allo stesso tempo, quindi non ci sono ritardi aggiuntivi.
L'esecuzione di un repository locale è il modo migliore per gestire esattamente ciò che è sui server locali. Inoltre, consente di distribuire facilmente backport personalizzati o pacchetti locali personalizzati. Sono stato conosciuto per creare "meta-pacchetti" locali che sono solo un'enorme quantità di dipendenze per facilitare l'installazione locale. (es. 'apt-get install local-mailserver'). Ciò ha l'effetto collaterale di consentire anche la "versione" delle modifiche alla configurazione. (Per una gestione della configurazione più complicata avrai bisogno di qualcosa come Puppet)
Per le nostre scatole di Windows abbiamo un server WSUS locale e una finestra standard per applicare le patch mensili. Per i sistemi Linux (RHEL) abbiamo un server satellitare RHN nel campus a cui sono tutti uniti. Ciò fornisce una bella dashboard di ogni sistema unito che amministrate, nonché gli aggiornamenti non applicati per ciascun sistema. Per quelli che si trovano nelle marionette, viene inviato uno script che applica automaticamente le patch durante una normale finestra e invia una notifica e-mail con i risultati.
È possibile disporre di un repository locale e configurare tutti i server in modo che puntino ad esso per gli aggiornamenti. Non solo ottieni la velocità dei download locali, ma puoi anche controllare quali aggiornamenti ufficiali desideri installare sulla tua infrastruttura al fine di prevenire eventuali problemi di compatibilità.
Per quanto riguarda Windows, ho usato Windows Server Update Services con risultati molto soddisfacenti.
Su OpenSuSE Linux, SLES e Novell OES (tutti i prodotti basati su SuSE), abbiamo uno script che esegue zypper e cerca i pacchetti che devono essere aggiornati. Quando ne trova uno, invia un ticket a JIRA e lo assegna agli amministratori di sistema. Quando installiamo gli aggiornamenti, chiudiamo il ticket, che lascia una traccia di controllo che ci dice quando è stato installato e da chi. Questo può essere riconciliato / confermato con i registri zypper e sudo, che sono centralizzati su un server di syslogging.
OPTIONS="-o Dir::Etc::SourceList=/etc/apt/security.sources.list"e quindi faccio /etc/apt/security.sources.list avere solo i repository di sicurezza Debian abilitati. In questo modo, ottengo tutti gli aggiornamenti di sicurezza installati automaticamente in modo tempestivo (ogni notte) e posso fare altri aggiornamenti più rischiosi che potrebbero rompere le cose a mano.