Respostas:
Em sistemas baseados em Linux / Debian, o cron-apt é uma ferramenta muito útil que pode gerenciar a automação do apt via cron.
Estou usando apt-get updatetodos os dias e me envie um email se novas atualizações tiverem que ser instaladas.
Aqui está uma introdução curta e bem-feita sobre essa ferramenta .
Em relação à sua terceira pergunta: eu sempre executo um repositório local. Mesmo que seja apenas para uma máquina, economiza tempo no caso de eu precisar reinstalar (geralmente uso algo como o aptitude autoclean) e, para duas máquinas, quase sempre compensa.
Para os clusters que eu administro, geralmente não mantenho logs explícitos: deixo o gerenciador de pacotes fazer isso por mim. No entanto, para essas máquinas (em oposição aos desktops), não uso instalações automáticas; portanto, tenho minhas anotações sobre o que pretendia instalar em todas as máquinas.
Eu uso o apt-history para história. Não tenho idéia do por que essa ferramenta útil não está incluída por padrão, é o primeiro pacote que implanto com o fantoche .
Eu executo / usr / bin / apt-get update -qq; / usr / bin / apt-get dist-upgrade -duyq como um trabalho cron todas as noites. De manhã, tenho uma notificação de quais pacotes precisam ser atualizados e os arquivos já foram baixados na máquina.
Normalmente, tiro uma foto da máquina (a maioria dos nossos servidores é virtual), faço um apt-get dist-upgrade , verifico os nagios e asseguro que tudo ainda está funcionando e removo a foto.
Por fim, mantenho uma lista contínua de todas as alterações feitas em todos os servidores de um wiki , a fim de rastrear os problemas que surgirem posteriormente.
Quanto a limitar downloads redundantes, entendo que você pode configurar um proxy da web em cache (squid?) Entre seus servidores e a Internet que armazenará em cache os arquivos .deb na primeira vez em que forem acessados. Talvez isso seja mais simples do que configurar um repositório de pacotes local - e tenha o benefício adicional de acelerar a navegação geral na web.
O apt-cacher é útil para armazenar pacotes em cache, ele fará o cache na primeira vez em que for necessário, em vez de completar um espelho completo de todo o repositório, economizando disco e largura de banda. Também é útil, pois transmite a primeira solicitação de um pacote diretamente ao solicitante enquanto o armazena em cache ao mesmo tempo, para que não haja atraso adicional.
A execução de um repositório local é a melhor maneira de gerenciar exatamente o que está em seus servidores locais. Ele também permite implantar facilmente backports personalizados ou pacotes locais personalizados. Sou conhecido por criar 'meta packages' locais, que são apenas uma enorme quantidade de dependências para facilitar a instalação local. (por exemplo, 'apt-get install local-mailserver'). Isso tem o efeito colateral de também permitir que você "versão" altere suas configurações. (Para um gerenciamento de configuração mais complicado, você precisará de algo como Puppet)
Para nossas caixas do Windows, temos um servidor WSUS local e uma janela padrão para aplicar os patches mensais. Para os sistemas Linux (RHEL), temos um servidor satélite da RHN no campus ao qual todos eles se juntam. Isso fornece um bom painel de todos os sistemas ingressados que você administra, bem como as atualizações não aplicadas para cada sistema. Para aqueles que estão fantoches, enviamos um script que aplica automaticamente os patches durante uma janela regular e envia uma notificação por email com os resultados.
Você pode ter um repositório local e configurar todos os servidores para apontar para atualizações. Além de obter velocidade dos downloads locais, você também controla quais atualizações oficiais deseja instalar em sua infraestrutura para evitar problemas de compatibilidade.
No lado do Windows, usei o Windows Server Update Services com resultados muito satisfatórios.
No OpenSuSE Linux, SLES e Novell OES (todos os produtos baseados em SuSE), temos um script que executa o zypper e procura por pacotes que precisam ser atualizados. Quando encontra um, ele envia um ticket ao JIRA e o atribui aos administradores do sistema. Quando instalamos as atualizações, fechamos o ticket, deixando uma trilha de auditoria que informa quando foi instalado e por quem. Isso pode ser reconciliado / confirmado com os logs zypper e sudo, centralizados em um servidor de syslogging.
OPTIONS="-o Dir::Etc::SourceList=/etc/apt/security.sources.list"e depois faço /etc/apt/security.sources.list ter apenas os repositórios de segurança Debian habilitados. Dessa forma, eu recebo todas as atualizações de segurança instaladas automaticamente em tempo hábil (a cada noite) e posso fazer outras atualizações mais arriscadas que podem quebrar as coisas manualmente.