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

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

Normalmente sou da opinião de que não está quebrado - não conserte. No entanto, após registrar o servidor na RHN e também usar o plug-in yum-security para verificar as atualizações de segurança, existem pouco mais de 1100 atualizações de "segurança" disponíveis.

Alguém já teve uma situação semelhante? Estou relutante em apenas atualizar tudo, pois gosto de saber o que está sendo atualizado e se tem ou não o potencial de afetar qualquer coisa em execução na caixa (este é um servidor de produção). No entanto, também parece que manter a linha com esta prática exigiria que eu percorresse 1100 erratas de pacotes linha por linha. Existe uma solução mais eficiente?

De um modo geral, as atualizações de segurança são consideradas um tanto seguras, principalmente para uma distribuição com objetivos como RedHat. Seu foco principal é criar um ambiente operacional consistente. Como tal, os mantenedores tendem a escolher versões dos pacotes e ficar com eles a longo prazo. Para ver o que quero dizer olhada nas versões de tais pacotes como kernel, python, perl, e httpd. O que eles também fazem é portar patches de segurança dos desenvolvedores upstream. Portanto, se uma vulnerabilidade de segurança for encontrada para todas as versões do Apache httpd 2.2.x, a fundação Apache poderá lançar a versão 2.2.40 com a correção, mas o RedHat lançará o patch localmente e lançará httpd-2.2.3-80com 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 suportam apenas determinadas sub-liberações. Recentemente, deparei com um software, por exemplo, que o fornecedor diz que só funciona na versão 5.4. Isso não significa que não funcionará na versão 5.9, mas pode significar que eles não fornecerão nenhum suporte se não funcionar.

Também há preocupações em fazer atualizações em massa de um sistema que não foi corrigido há tanto tempo. O maior que eu me deparei é, 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á depois que você aplicar as atualizações do kernel, talvez não seja realmente reiniciado. Ou pode agir diferente quando reiniciar.

Meu conselho seria fazer as atualizações, mas seja esperto.

• Planeje-o durante uma janela de manutenção. Se nada mais exigir que o servidor seja reiniciado, houve várias atualizações do kernel e você precisará reiniciar para aplicá-las.
• Certifique-se de fazer um backup completo antes de fazer qualquer coisa. Pode ser uma captura instantânea, se for uma VM, acionando um backup completo de qualquer ferramenta que você esteja usando, segmentando /(para outro sistema), capturando uma ddimagem das unidades, o que seja. Contanto que seja algo que você possa restaurar.
• Planeje como você aplica as atualizações. Você não quer apenas tentar yum update -ye ir embora. Para todas as coisas boas que o yum faz, ele não ordena quando aplica 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 se reformular. Temos RHEL6 por um bom tempo agora. Dependendo do que esse servidor faz, pode fazer sentido deixar este funcionar como está enquanto você abre uma nova instância em paralelo. Depois de instalado, você pode 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 esse jazz.

Não importa o que você faça, sinto que é muito importante que você se adapte a um sistema atual. Você só precisa fazer isso de uma maneira que permita confiar no seu trabalho e no produto acabado.

Na minha experiência, o RHEL não quebra a compatibilidade com versões anteriores nas atualizações da mesma versão.

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

Você pode usar rpm -qfpara encontrar os arquivos que você suspeita serem compilados externamente. Se ele retornar "não pertence a nenhum pacote", poderá haver problemas na atualização.

Eu pegava uma imagem do servidor e fazia a atualização, sou um pouco mais preocupada do que a maioria.