Gerenciamento de atualizações : uma solução simples e eficaz

Para aqueles, como eu, que precisam administrar dezenas de servidores e mantê-los atualizados em relação a aplicação de atualizações de segurança, a forma mais fácil de cumprir essa tarefa seria automatizá-la ao máximo.

Porém, quando o assunto é aplicação 100% automatizada de novas versões de pacotes de softwares em servidores de produção sem intervenção humana alguma, eu tendo a ter um nível de aceitação bastante baixo para essa idéia, por razões óbvias.

A solução, em meu caso, foi adotar uma solução que automatiza parcialmente o processo de gerenciamento de atualizações. A parte que exige mais participação intelectual, ou seja, a aplicação das atualizações propriamente ditas, eu mesmo prefiro executar manualmente, visto que posso interferir caso qualquer problema maior ocorra.

Como utilizo Debian GNU/Linux na imensa maioria dos servidores que administro, as tarefas de checar pela disponibilidade de atualizações e fazer o download das mesmas são triviais, já que existe suporte para fazê-las de forma bastante simples nas ferramentas de gerenciamento de pacotes nativas do próprio sistema operacional.

Porém, mesmo com a simplicidade e facilidade fornecida por essas ferramentas, quando a quantidade de servidores a ser administrada cresce a tarefa de ter que checar pela disponibilidade das atualizações, verificar a aplicabilidade de cada uma delas a cada um dos servidores administrados e fazer o download das mesmas, deixando as atualizações guardadas em um cache local para posterior aplicação, é algo que começa a consumir um tempo bastante grande.

Para facilitar, adotei já há alguns anos uma solução de gerenciamento de atualizações (que pode ser configurada para aplicar automaticamente as atualizações de maneira relativamente simples, mas não pretendo usar essa funcionalidade) bastante simples que cumpre essas tarefas de forma bastante satisfatória.

Trata-se do apticron, um script shell bem simples e disponível como um pacote Debian nos repositórios oficiais de pacotes Debian. Instalá-lo é tão simples quanto instalar qualquer outro pacote Debian comum, ou seja, ele se encontra somente a um aptitude install de distância 🙂

Após instalá-lo, costumo modificar somente duas variáveis no arquivo de configuração /etc/apticron/apticron.conf : a variável de nome EMAIL e a variável de nome LISTCHANGES_PROFILE.

Para a primeira variável, forneço como valor o endereço de e-mail no qual eu desejo receber as mensagens de aviso que serão enviadas pelo apticron quando novas atualizações estiverem disponíveis e, no caso da segunda, simplesmente descomento a linha que define a variável, deixando a mesma com o valor apticron.

Isso faz com que, ao enviar as mensagens de aviso de atualizações aplicáveis aos seus servidores, o apticron obtenha a saída do utilitário apt-listchanges (mais um utilitário interessante disponível também como um pacote Debian nos repositórios oficiais Debian e também somente a um aptitude install de distância) e a envie juntamente as mensagens de aviso, o que lhe permite conhecer, além dos pacotes e versões novas disponíveis para instalação, a lista de mudanças (o changelog) dos pacotes para os quais existam atualizações disponíveis.

Além de lhe avisar sobre as atualizações disponíveis e aplicáveis aos seus servidores, o apticron, por padrão, já faz o download das mesmas e as deixa no cache local de pacotes de seu gerenciador de pacotes, de forma que, posteriormente, você precise somente se conectar ao servidor analisado pelo apticron e executar o comando a seguir :


# aptitude upgrade

Pronto. As atualizações deixadas em seu cache local de pacotes serão utilizadas e aplicadas em seu servidor, da mesma forma como você costuma atualizar seus pacotes Debian em um processo usual, sem o envolvimento de nenhuma ferramenta de gerenciamento de atualizações como o apticron.

A execução do apticron ocorre diariamente (por padrão, mas isso pode ser modificado conforme sua necessidade) junto a execução das tarefas agendadas para execução com periodicidade diária pelo cron, sob o diretório /etc/cron.daily (mais especificamente, no arquivo /etc/cron.daily/apticron).

Como se trata de um script shell simples (em /usr/sbin/apticron), o apticron pode ser modificado facilmente, inclusive para que as atualizações já sejam aplicadas automaticamente após o donwload das mesmas, caso desejado.

Novamente, isso não seria algo que eu recomendaria, visto que existem diversos detalhes a serem observados durante uma atualização e decisões que precisam ser tomadas por um intelecto humano (e não por um script shell simples), as quais, nem sempre, possuem uma resposta padrão válida para todos os casos.

De qualquer forma, acredito que o apticron cumpre realmente as tarefas que se propõe a cumprir, de forma simples e descomplicada. Para outras necessidades mais exóticas, uma possibilidade seria utilizar o cron-apt.

Pessoalmente, posso dizer que já utilizei o cron-apt e acabei optando pelo apticron por esse último ser mais simples, cumprir somente as tarefas que eu realmente precisaria automatizar (sem mais nem menos) e funcionar de forma mais confiável que o cron-apt em meus testes.

Por último, apesar de ser evidente para os leitores que chegaram até aqui, esta é uma solução específica para distribuições GNU/Linux baseadas em pacotes Debian. Qual a solução que vocês utilizam para seus servidores, sejam eles baseados em um sistema de gerenciamento de pacotes Debian ou não ? Deixe suas dicas, experiências e indicações nos comentários.

Anúncios

5 comentários sobre “Gerenciamento de atualizações : uma solução simples e eficaz

  1. Oi André,

    Eu utilizo o cron-apt e faço o upgrade automático com ele. Só uma dica, os pacotes que vem do repositório de segurança não pergunta nada ao usuário, portanto é seguro colocá-los para serem atualizados (nesse caso, é importante especificar etch ao invés de stable no sources.list para evitar problemas com uma nova versão).

    Eu também coloco o repositório main do Debian stable para atualização automática, uma vez que ele não adiciona funcionalidades aos softwares (apenas corrige bugs), provavelmente novas perguntas não acontecerão (perguntas que você já respondeu, pelo que já percebi — mas não posso confirmar — não são perguntadas novamente).

    Até,
    semente

    PS: eu utilizo um sources.list separado para o cron-apt apenas com repositórios “stable/main”, daí em servidores que preciso de outros repositórios não correrão o risco de serem atualizados automaticamente.

  2. Olá Guilherme,

    É importante deixar claro que não é porque somente devido ao fato de, até o momento, você não ter tido nenhuma pergunta adicional para pacotes originados dos repositórios de atualizações de segurança isso signifique que nenhuma pergunta irá aparecer.

    Não existe nada na política de empacotamento Debian que forneça um tratamento especial as atualizações de segurança nesse sentido, portanto, nunca se pode garantir que esse tipo de problema não acontecerá.

    Logicamente, a idéia é sempre ter todos os pacotes Debian utilizando debconf para gerenciamento básico de configuração inicial (mas não para toda a configuração, como um registro do Microsoft Windows, por exemplo).

    Com isso, ganha-se com o fato do debconf lembrar suas últimas respostas as perguntas feitas anteriormente e não lhe fazer novamente as mesmas perguntas.

    De qualquer forma, mesmo não se tendo certeza sobre suas respostas anteriores (e isso é fácil de se checar) é relativamente fácil usar pré-alimentação debconf (debconf preseeding) para fornecer as respostas para as perguntas antes que as mesmas sejam feitas.

    De qualquer forma, esse é um tema recorrente nas diversas listas de discussão do projeto Debian e sempre que a discussão retorna, depois de muita discussão, no final sempre se acaba chegando a conclusão de que atualizações 100% automatizadas (ainda mais em ambientes de produção) não são recomendadas por ainda não ser algo completamente suportado.

    Infelizmente, pessoalmente acredito que isso não será algo suportado por um bom tempo. Lógico que todos os pacotes deveriam seguir 100% as políticas de empacotamento e deixar os arquivos de configuração intocados quando detectam alguma modificação feita manualmente, mas, apesar de muito avança ter sido feito nesse sentido, ainda não estamos 100% lá ainda.

    Sei também que atualizações de segurança não introduzem novas funcionalidades devido a não ser permitido a inclusão de novas versões de softwares como política do projeto e isso ajuda bastante no sentido de termos confiança em não termos surpresas desagradáveis na aplicação de atualizações de segurança, mas, ainda assim, não se trata de algo 100% suportado e nem mesmo indicado.

    Basicamente é : faça por sua conta e risco. E, quando o risco não é somente meu mas sim de servidores de produção de meus clientes, prefiro seguir o conselho de quem desenvolve a tecnologia que estou usando a me aventurar 🙂

    Obrigado pelo comentário.

  3. Oi André,

    estou usando o apticron também, mas tem algo chato com ele que é o fato de não respeitar os pacotes que estão em hold. Em uma máquina Ubuntu em que precisava do repositório backports, eu tive que colocar o postfix em hold e recebo o aviso todos os dias da atualização. Pode-se argumentar que o repositório de backports não deveria ter sido adicionado, mas ainda acho que deveria ter uma opção de respeitar os pacotes on hold.

  4. Olá Thadeu,

    Realmente, esse comportamento é meio chato mesmo. Andei pesquisando sobre o assunto e inclusive existe um bug aberto sobre o caso, em http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431869 .

    Eu até mesmo enviei uma mensagem para acrescentar uma informação ao bug citado acima hoje ao receber seu comentário.

    É interessante observar que em outro bug citado nos comentários, o bug em http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174091, o desenvolvedor do aptitude comenta que o problema parece ocorrer somente quando se coloca um pacote em hold usando o aptitude em linha de comando e não usando a interface ncurses do mesmo.

    Não sei se é muit válido essa observação já que, como eu acrescentei nos comentários do primeiro bug citado, o apticron, apesar de recomendar o uso do aptitude em suas mensagens de notificação, não faz uso do mesmo internamente e sim do apt-get.

    Vou acompanhar esses bugs pois também estou interessado em ver esse comportamento que também considero chato corrigido, se possível.

    Obrigado pelo comentário.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s