Com que frequência devo atualizar nosso servidor Linux?

Sou responsável por gerenciar nosso servidor de produção (correio, web, banco de dados, todos em um servidor) e nosso servidor de teste. Ambos são construídos no Debian. No entanto, como eu sou muito novo na administração do sistema, só instalei atualizações porque me deparei com coisas que precisam ser atualizadas para que eu possa ter recursos mais novos e obter correções de bugs. É um processo bastante ad hoc no momento, e eu gostaria de torná-lo menos.

Então, eu estou me perguntando como as pessoas que sabem o que estão fazendo lidam com isso. Com que frequência você realiza atualizações em seus servidores? O processo de atualização é diferente entre teste e produção? Você sempre atualiza primeiro os servidores de teste? E você faz uma atualização completa de todos os softwares ou apenas instala atualizações selecionadas?

Eu executo o apt-get update -qq; apt-get upgrade -duyq diariamente. Isso verificará atualizações, mas não as fará automaticamente.

Então, eu posso executar as atualizações manualmente enquanto estou assistindo e corrigir qualquer coisa que possa dar errado.

Além das preocupações de segurança de manter um sistema corrigido, acho que, se eu demorar muito entre os patches, acabarei com um monte de pacotes que desejam ser atualizados, e isso me assusta muito mais do que apenas atualizar um ou mais duas a cada semana mais ou menos. Portanto, costumo executar minhas atualizações semanalmente ou, se forem de alta prioridade, diariamente. Isso tem a vantagem adicional de saber qual pacote quebrou seu sistema (por exemplo, se você estiver atualizando apenas um par de cada vez)

Sempre atualizo sistemas menos críticos primeiro. Também tenho um "plano de reversão" para o caso de não conseguir consertar o sistema. (como a maioria de nossos servidores é virtual, esse plano de reversão geralmente consiste em tirar uma captura instantânea antes da atualização para a qual eu posso reverter, se necessário)

Dito isto, acho que uma atualização quebrou algo apenas uma ou duas vezes nos últimos 4 anos, e que estava em um sistema altamente personalizado - para que você não precise ser MUITO paranóico :)

Sobre as respostas anteriores - algumas coisas mais específicas do Debian: você deve se inscrever em debian-security- Announce e debian-Announce e / ou confira a página de segurança da Debian .

Supondo que você esteja executando o lançamento estável do Debian, a maioria dos patches estará relacionada à segurança ou a erros, o que significa que não haverá muitas mudanças importantes entre as versões de um pacote. De acordo com a política de patches da debian, os patches também deveriam estar em teste há algum tempo antes de serem movidos para o ramo estável pelo mantenedor. Obviamente, isso não interrompe as quebras durante o patch, mas deve evitá-las na maioria dos casos.

Seria prudente garantir que o seu servidor de testes seja atualizado e todos os pacotes com erros que afetam você e seus servidores devem ser atualizados. Todos os pacotes que possuem avisos de segurança devem ser atualizados assim que você souber que o patch está estável.

O Debian geralmente é um sistema operacional muito estável e não um com o qual você deve se preocupar muito com quebras, mas sempre leia o que será atualizado antes de ser atualizado e fique de olho em qualquer coisa que pareça estranha. Eu uso VCS no meu / etc / dir também para garantir que qualquer alteração no arquivo de configuração possa ser vista com um comando 'git diff'.

Eu faço uma corrida a seco (primeiro) para ver o que será atualizado. Às vezes, as bibliotecas (vamos chamá-lo de libfoo neste exemplo) alteram sua API, o que interrompe os programas que nós mesmos escrevemos / instalamos. Se alguma biblioteca crítica for atualizada, eu pego a fonte e tento reconstruir nossas coisas antes de atualizar.

Também verifico se não estamos saltando para uma versão intermediária de algum serviço público, como o apache, etc. Prefiro ficar um ano atrás e não encontrar falhas aleatórias, a menos que a atualização seja crítica.

Se você é um administrador de sistema, deve extrair feeds RSS de sites como o Secunia , que devem informar com antecedência se a sua distribuição vai enviar alguns patches.

Nunca, nunca apenas atualizar / atualizar cegamente. Infelizmente, a tarefa de saber o que está quebrado recai sobre você, não sobre o seu gerenciador de pacotes de distribuição, especialmente se seus sistemas suportam programadores.

Onde trabalho, temos um processo bastante extenso que envolve o uso de software chamado PatchLink para nos notificar sobre as atualizações mais importantes relacionadas à segurança e as aplicamos após o teste, pacote por pacote. Porém, temos milhares de servidores.

Se você tiver apenas dois servidores, o processo deverá ser muito mais simples. Embora eu não ache que fazer uma "atualização / atualização do apt-get" seja sua melhor aposta.

Eu monitorava os patches do software que você está executando e tomava decisões com base nas correções nessas versões sobre quando atualizar.

Como você possui um servidor de teste, obviamente, sempre teste a atualização antes de aplicá-la.

As atualizações manuais são as melhores, conforme mencionado aqui, no sentido de que você pode ver o que está acontecendo. No entanto, para um número muito grande de servidores, isso pode se tornar impraticável. A execução a seco é uma prática padrão; na verdade, a maioria dos gerenciadores de pacotes pergunta antes de prosseguir.

Atualizar regularmente tende a ser melhor, embora possa ser um pouco de equilíbrio. Atualizações frequentes significam menos de uma só vez e menos erros de uma só vez. Se as coisas derem errado, há menos candidatos a inspecionar. Os pacotes também são um pouco melhores na atualização em etapas menores, como geralmente quando o programador atualiza a visualização da última versão para a próxima, se eles prestam alguma atenção além da última versão pode variar, embora isso tenda a importar principalmente para softwares que estão evoluindo rapidamente.

Nem todas as atualizações são ininterruptas. Você vai querer tomar cuidado com isso. Alguns reiniciarão os serviços levando a tempo de inatividade.

Em uma configuração ideal, você pode ter o seguinte:

• Um meio de alternar aparentemente servidores (A / B ou tick tock). Isso significa que você atualiza um enquanto está no banco e simplesmente troca o tráfego do atual para o novo. Isso pode ser mais complicado para serviços como bancos de dados.
• A capacidade de testar atualizações. Você deve ter servidores de teste que são praticamente clones de produção (mas sem se conectar a nenhum serviço de produção). Isso permitiria testar as atualizações primeiro.
• Uma boa estratégia de backup incremental é ideal. Nunca se sabe. É sempre melhor prevenir do que remediar.
• Esteja ciente de quais horários têm mais atividade e qual nível de tempo de inatividade é tolerável.
• Saiba como reverter uma atualização ou um pacote específico.
• Tenha seu próprio pacote espelhado para que as atualizações sejam consistentes e previsíveis entre os servidores. Este é o primeiro passo para um sistema autônomo decente em que você pode confiar. Isso significa que você pode atualizar o espelho, executar a atualização em uma ou mais máquinas de teste; se isso for bom, deixe-o sair automaticamente. Eu me diverti muito com o gerenciamento adequado de cerca de 800 máquinas EPOS.
• Um bom nível de consistência para que você saiba que, se algo funcionar aqui, funcionará lá.

Alguns deles podem ser um exagero em vários graus para pequenas configurações, mas devem ser lembrados.

De um modo geral, as atualizações geralmente são relativamente simples para distribuições de servidores. Isso ocorre porque eles sempre mantêm apenas correções de bugs e atualizações de segurança. No entanto, você pode ter problemas se as pessoas fizerem coisas estranhas no sistema ou adicionar fontes de pacotes adicionais.

Embora seja moderadamente raro, eles ocasionalmente cometem erros e quebram a compatibilidade entre versões menores de pacotes.

Eu gosto do cron-apt para automatizar esse processo, mas como o @dinomite apontou em outra pergunta sobre atualizações, configurá-lo especificamente para automatizar atualizações relacionadas à segurança é uma idéia muito inteligente - você pode atualizar manualmente o que precisa. Eu estava usando o cron-apt para todas as atualizações, mas realmente mudei isso com base em sua resposta. Se você gosta, provavelmente deve votar a resposta dele em vez desta.

No debian, instalo o cron-apt e edito seu arquivo de configuração para me enviar um e-mail se houver alguma alteração. Dessa forma, eu sou notificado se houver atualizações para meus sistemas e as faço manualmente

Na mesma linha do cron-apt, você deve dar uma olhada no pacote de atualizações autônomas http://packages.debian.org/lenny/unattended-upgrades .

É muito fácil de configurar e permitirá que você baixe e aplique atualizações de segurança automaticamente, mas deixe outras atualizações para atualização manual (ou, a seu critério, atualize tudo!).

O Guia Oficial do Servidor Ubuntu, possui uma seção razoavelmente detalhada que cobre o uso do pacote de atualizações autônomas https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html

Nota: dependendo do seu nível de cautela / paranóia, você pode fazer uma atualização sem interrupção em um grupo de servidores de teste primeiro e, se não houver problemas, permita que suas caixas de produção sejam atualizadas, embora eu pessoalmente não tenha encontrado nenhum problema com as atualizações de segurança destruindo estragos até agora (bata na madeira) ...

Também existe uma opção de configuração para enviar por e-mail os resultados de cada atualização de segurança, uma vez aplicada. Além disso, se houver algum diálogo ou avisos interativos que foram apresentados durante a atualização, aqueles que precisarão de ajustes manuais por um administrador de sistemas, ele também será mencionado.

Pessoalmente, desativo as atualizações automáticas e não realizo regularmente nenhum tipo de atualização de pacotes nos servidores em meus ambientes, a menos que: (a) exista um aviso importante do CERT para um dos pacotes no meu sistema; (b) preciso atualizar pacotes individuais por motivos específicos; (c) OS ou pacotes estão chegando ao final do ciclo, não terão mais suporte e precisamos continuar com o suporte. Meu raciocínio é que atualizar sem saber o que está sendo alterado ou por que deixa muito espaço para algo quebrar. Eu venho fazendo coisas assim há 14 anos e funciona bem.

Além das coisas mencionadas, você deve usar algum tipo de ferramenta de monitoramento (Nagios ou o que flutua no seu barco) para alertá-lo sobre atualizações.

Quanto à frequência: assim que houver uma atualização disponível!