Em sistemas baseados em Linux / Debian, o cron-apt é uma ferramenta muito útil que pode gerenciar a automação apt via cron.
Estou usando-o para apt-get update todos os dias e envie-me um e-mail se novas atualizações tiverem que ser instaladas.
Aqui está uma introdução breve 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 precisar reinstalar (geralmente uso algo como o autoclean do aptitude) e, para duas máquinas, quase sempre compensa.
Para os clusters eu admin, geralmente não guardo logs explícitos: deixo o gerenciador de pacotes fazer isso por mim. No entanto, para essas máquinas (em oposição a desktops), não uso instalações automáticas, portanto, tenho minhas anotações sobre o que pretendia instalar em todas as máquinas.
Similar ao cron-apt, eu uso apticron .
Eu uso apt-history para a história. Não tenho ideia de por que essa ferramenta útil não está incluída por padrão, é o primeiro pacote que implanto com o boneco .
Eu corro / usr / bin / apt-get update -qq; / usr / bin / apt-get dist-upgrade -duyq como uma tarefa cron toda noite. De manhã eu tenho uma notificação de quais pacotes precisam ser atualizados, e os arquivos já foram baixados na máquina.
Em seguida, normalmente, faço um instantâneo da máquina (a maioria dos nossos servidores é virtual), faço um apt-get dist-upgrade , verifico nagios e asseguro que tudo está ainda está funcionando e remova o instantâneo.
Por fim, mantenho uma lista de todas as alterações feitas em todos os servidores em um wiki , a fim de rastrear quaisquer problemas que possam surgir posteriormente.
No que diz respeito à limitação de downloads redundantes, eu entendo que você pode configurar um web-proxy de cache (squid?) entre seus servidores e a internet que armazenará em cache os arquivos .deb na primeira vez que são acessados. Talvez isso seja mais simples do que configurar um repositório de pacotes local - e tem o benefício adicional de acelerar a navegação geral na Web.
O apt-cacher é útil para armazenar pacotes em cache, ele armazena em cache a primeira vez que eles são necessários, 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 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. Eu sou conhecido por fazer 'meta pacotes' locais que são apenas um enorme pacote de dependências para facilitar a instalação local. (por exemplo, 'apt-get install local-mailserver'). Isto tem o efeito colateral de também deixar você 'version' mudar sua configuração. (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 as correções mensais. Para os sistemas Linux (RHEL), temos um servidor de satélites da RHN no campus ao qual todos estão associados. Isso fornece um bom painel de controle de cada sistema associado que você administra, bem como as atualizações não aplicadas de cada sistema. Para aqueles que estão no fantoche, enviamos um script que auto aplica patches durante uma janela normal e envia uma notificação por e-mail com os resultados.
Você pode ter um repositório local e configurar todos os servidores para que ele aponte para atualizações. Além de obter velocidade de downloads locais, você também pode controlar 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 muito resultados satisfatórios.
When using a package manager like Aptitude, do you keep an upgrade / install history, and if so, how do you do it?
o apt mantém um login em / var / log / apt /, e o dpkg usa /var/log/dpkg.log. O dpkg, em particular, é bastante parsável.
No OpenSuSE Linux, SLES e Novell OES (todos produtos baseados em SuSE), temos um script que executa o zypper e procura pacotes que precisam ser atualizados. Quando ele encontra um, ele envia um ticket para o JIRA e o atribui aos administradores de sistema. Quando instalamos as atualizações, fechamos o ticket, o que deixa uma trilha de auditoria que nos informa quando foi instalado e por quem. Isso pode ser reconciliado / confirmado com os logs zypper e sudo, que são centralizados em um servidor syslogging.