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.