Práticas recomendadas para atualizar um servidor previamente não-mantido RHEL5.7

Question

Um novo servidor RedHat EL5.6 foi recentemente colocado sob meus cuidados. É imediatamente óbvio que, nos últimos 12 meses, pouca ou nenhuma atenção foi dada a qualquer tipo de atualização de pacotes.

Normalmente eu sou da mentalidade de se não está quebrado - não conserte. No entanto, depois de registrar o servidor com o RHN, e também usando o plugin yum-security para verificar as atualizações de segurança, há pouco mais de 1100 atualizações de "segurança" disponíveis.

Alguém teve uma situação semelhante? Estou relutante em apenas atualizar tudo, pois gosto de saber o que está sendo atualizado e se ele tem ou não o impacto de qualquer coisa que esteja sendo executada na caixa (esse é um servidor de produção). No entanto, também parece que manter-se em linha com essa prática exigiria que eu passasse 1100 pacotes de erratas linha por linha. Existe uma solução mais eficiente?

    

Answer 1

Geralmente falando, atualizações de segurança são consideradas um pouco seguras, particularmente para uma distribuição com objetivos como o RedHat. Seu foco principal é a criação de um ambiente operacional consistente. Como tal, os mantenedores tendem a escolher versões de pacotes e ficar com eles por um longo período. Para ver o que quero dizer, veja as versões desses pacotes, como kernel , python , perl e httpd . O que eles também fazem é os patches de segurança backport dos desenvolvedores upstream. Portanto, se for encontrada uma vulnerabilidade de segurança para todas as versões do Apache httpd 2.2.x, a base do Apache pode liberar a versão 2.2.40 com a correção, mas o RedHat irá aplicar o patch localmente e liberar httpd-2.2.3-80 com a correção.

Lembre-se também de que você está falando sobre um sistema RHEL5.7, a versão atual é 5.9. Alguns fornecedores de software suportarão apenas certos sub-pacotes. Recentemente, encontrei uma peça de software, por exemplo, que o fornecedor diz que só funciona na versão 5.4. Isso não significa que não será executado em 5.9, mas isso pode significar que eles não fornecerão nenhum suporte se não funcionarem.

Também há preocupações com atualizações em massa de um sistema que não foi corrigido em um tempo tão longo. O maior problema com o qual me deparo é, na verdade, mais um problema de gerenciamento de configuração que pode ser exacerbado por grandes atualizações. Às vezes, um arquivo de configuração é alterado, mas o administrador nunca reinicia o serviço. Isso significa que a configuração no disco nunca foi testada e a configuração em execução pode não existir mais. Portanto, se o serviço for reiniciado, o que acontecerá quando você aplicar as atualizações do kernel, ele poderá não ser reiniciado. Ou pode agir diferente uma vez que é reiniciado.

Meu conselho seria fazer as atualizações, mas tenha cuidado com isso.

• Planeje durante uma janela de manutenção. Se nada mais o servidor necessitar de reiniciar, houve uma série de atualizações do kernel e você terá que reinicializar para aplicá-las.
• Certifique-se de fazer um backup completo antes de fazer qualquer coisa. Isso pode ser instantâneo, se for uma VM, acionando um backup completo em qualquer que seja a sua ferramenta, carregando / (para outro sistema), pegando uma imagem dd das unidades, seja qual for. Contanto que seja algo que você possa restaurar.
• Planeje como você aplica as atualizações. Você não quer apenas jogar yum update -y e ir embora. Para todas as coisas boas que o yum faz, não o faz quando ele aplica as atualizações de acordo com as dependências. Isso causou problemas no passado. Eu sempre corro yum clean all && yum update -y yum && yum update -y glibc && yum update . Isso tende a cuidar da maioria dos possíveis problemas de pedidos.

Esse também pode ser um ótimo momento para replantar. Já tivemos RHEL6 por um bom tempo agora. Dependendo do que este servidor faz, pode fazer sentido apenas deixar este funcionar como está enquanto você traz uma nova instância em paralelo. Então, uma vez instalado, você poderá copiar todos os dados, testar os serviços e executar o corte. Isso também lhe dará a chance de saber, desde o início, que o sistema é padronizado, limpo, bem documentado e todo aquele jazz.

Não importa o que você faça, eu sinto que é muito importante que você se coloque em um sistema atual. Você só precisa certificar-se de fazê-lo de uma forma que lhe permita confiar em seu trabalho e no produto acabado.

    

Answer 2

Na minha experiência, o RHEL não quebra a compatibilidade retroativa nas atualizações do mesmo lançamento.

que, no entanto, não se estenderá a nada que tenha sido instalado externamente a rpm.

Você pode usar rpm -qf para encontrar os arquivos que você suspeita serem compilados externamente, se ele retornar "não pertence a nenhum pacote", então você pode ter problemas em sua atualização.

Eu pegaria uma imagem do servidor e faria a atualização, eu sou um pouco mais demônio do que a maioria no entanto.