Para atualizar? Ou não?


13

perdoe esta pergunta bastante direta.

Primeiro, não sou administrador de sistemas e minha experiência com o Linux é um pouco limitada.

Cerca de 3 a 4 meses atrás, configurei um servidor CentOS em funcionamento, por vários motivos. Estamos usando-o como servidor de desenvolvimento de sites (aos quais nossos clientes têm acesso), servidor de subversão e também hospedamos um wiki para comunicação interna, tornando-se uma ferramenta bastante importante para nós. (Provavelmente mais importante do que pensávamos quando o configurei!)

Chegou ao meu conhecimento que o Yum deseja atualizar cerca de 250 pacotes para as versões mais recentes do repositório.

Como o servidor está funcionando bem para nós, devo correr o risco de atualizar esses pacotes? Os riscos de segurança superam o risco de quebra do servidor quando eu atualizo tudo?

Devo salientar que, embora eu tenha backups de tudo, levaria tempo para configurar tudo do jeito que está agora, e não tenho muito tempo livre no trabalho no momento!

Se o conselho for atualizar, existem práticas recomendadas que possam ser transmitidas para tornar o processo o mais seguro possível?

Agradecemos antecipadamente por qualquer conselho.

ATUALIZAÇÃO - Obrigado por suas respostas a todos. Se eu tivesse representante suficiente para votar em todos, teria. ;) Decidi fantasmar o disco rígido e atualizar. Infelizmente, não é possível encontrar um administrador de sistemas de tempo integral ou parcial, então, vou ter que lidar com o problema da melhor maneira possível!

Respostas:


12

Solução rápida e suja (por exemplo, administrador do Battlefield):

  1. Coloque seu sistema offline (espero que você possa) e faça um backup do NortonGhost (ou algo semelhante) para um segundo disco rígido.

  2. Inicialize o segundo disco rígido (para garantir que seu backup realmente funcione) e faça a atualização yum nessa unidade.

  3. Se tudo funcionar ... parabéns!

  4. Se estragar alguma coisa ... vá em frente, coloque sua unidade ORIGINAL e crie um "Plano B".

ATUALIZAR:

Só pensei em mencionar que o problema real aqui é "Atualizo meu sistema desatualizado e arrisco-o a estragar tudo?" ou "Deixo meu sistema de trabalho perfeitamente bom sem patches e corro o risco de ser invadido / comprometido?"

A resposta é ... assim que o sistema estiver corrigido através das etapas acima ... tente manter-se atualizado, fazendo backup com freqüência E corrigindo com freqüência.

Então você terá o melhor dos dois mundos. ;-)


O prazer é meu ... boa sorte com seu backup / atualização. Como uma observação lateral, eu fiz pessoalmente as atualizações do yum no CentOS quando houve 200 a 300 atualizações e tudo correu bem. MAS ... Eu também fiz atualizações em que tudo estava completamente fragmentado e tive que fazer rituais de vodu / galinha (e muita porcaria na linha de comando) apenas para fazer as coisas funcionarem novamente. Desejo a você uma atualização rápida e bem-sucedida. ;-)
KPWINC 07/07/2009

10

Sim, atualize.

O RHEL (e, portanto, o CentOS) tem o cuidado de não atualizar as versões para algo incompatível. Em vez disso, eles suportam correções de bugs e correções de segurança; portanto, as mudanças reais nos pacotes são mínimas e razoavelmente improváveis ​​que causem problemas de compatibilidade.

Se algum arquivo de configuração foi alterado, os pacotes informarão sobre um arquivo .rpmorig ou .rpmnew que é criado. Depende da configuração do próprio RPM. Você pode procurar avisos sobre qualquer um dos que estão sendo criados e colocar sua configuração antiga de volta (" cp foo foo.bak; cp foo.rpmorig foo") ou ver os arquivos .rpmnew e incorporar quaisquer alterações à sua configuração.

O problema é menos perceptível se você atualizar regularmente.

Temos muitos sistemas que são atualizados trimestralmente (a cada 3 meses); e raramente vêem problemas nas atualizações de pacotes. (exceto em sistemas que fazem coisas estranhas no kernel para acessar LUNs de uma SAN)


Eu gosto de mais respostas KPWINC. Faça backup primeiro. Exemplo: o httpd 2.2 foi atualizado para 2.4 e, de repente, os arquivos de configuração não funcionam mais. A equipe de pânico e de desenvolvimento fica ociosa por horas até que o problema seja diagnosticado e corrigido.
Jose Manuel Gomez Alvarez

Para não falar da atualização do pacote do kernel, que pode potencialmente interromper a inicialização da máquina access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…
Jose Manuel Gomez Alvarez

@ Manuel Manuel Gomez Alvarez - o backup primeiro é sempre bom, mas se o seu sistema passou de http 2.2 para 2.4, não correspondeu a essa pergunta - o CentOS nunca faz esse tipo de coisa.
freiheit

6

Embora sim, levaria tempo para atualizar. E, na mesma mansão, levaria tempo para restaurar se algo desse errado. Quanta dor / sofrimento seria se os dados nesse sistema fossem excluídos por meio de uma exploração / invasão?

Na maioria das vezes, é seguro instalar as atualizações dos repositórios base do CentOS. A única vez em que tive problemas de atualização com o CentOS é quando inicio / ou preciso usar um repositório externo (DAG, RPMForge, Ect etc.)

A melhor configuração para esse tipo de coisa é ter um servidor hot-swap pronto para que você possa testar as atualizações antes de implantá-las no servidor ativo.


3

Parece que você precisa de um administrador de sistema real para levar algumas horas para examinar seu sistema, atualizá-lo e garantir que tudo funcione novamente. Idealmente, você gostaria que essa pessoa viesse fazer isso algumas vezes por mês. Um servidor não é uma coisa de instalar uma vez e esquecer; precisa de serviço regular.


3

Se esse sistema é tão importante, as atualizações de segurança se tornam ainda mais importantes. Considere as implicações se esse sistema precisar ser desativado para uma reconstrução se (quando?) Um pacote desatualizado permitir um comprometimento do sistema. Idealmente, você teria um servidor de teste configurado de maneira semelhante ao que poderia atualizar primeiro e verificaria se algo quebra.

Ao aplicar atualizações, você precisa se certificar de algumas coisas:

  1. O tempo de atualização é divulgado a todos que usam o sistema
  2. Você tem um plano sobre como atualizar e testar cada aplicativo
  3. Você tem um plano para desfazer as atualizações se (quando?) A atualização interromper o aplicativo
  4. E existem backups atuais caso algo dê realmente errado

Um bom administrador de sistemas teria experiência nesse tipo de trabalho e deveria estar fazendo todas essas coisas de qualquer maneira. Se sua organização tiver alguma, talvez seja o momento de despejar a administração do sistema nelas. Ou se você está nervoso em fazer isso sozinho, procure contratar alguém contratado para fazer esse tipo de manutenção de rotina. De qualquer forma, as atualizações precisam acontecer, pois você está se abrindo para uma situação muito pior no futuro.


3

É por isso que hoje quase nunca executo sistemas de produção em hardware real. Eu os executo em máquinas virtuais. Então, durante um tempo de inatividade rápido (5 minutos), eu executo um instantâneo no próprio ESX ou, se estou usando uma configuração personalizada do Xen / Solaris / OpenVZ, faço um instantâneo LVM da imagem do servidor. Em seguida, inicializo o backup original e agora tenho uma cópia com a qual posso fazer o que quiser.

Dito isto, comece com a atualização do kernel e do apache e depois trabalhe de trás para frente. Você não precisa levar a lista completa de pacotes que o yum relata, mas os principais vetores de ataque devem ser os que você corrigir mais rapidamente.

Toda vez que um sistema Linux foi hackeado, deixei o apache, o openssh ou o próprio kernel sem patch.


2

Gostaria apenas de atualizar os pacotes relacionados à segurança.


2

Eu fiz exatamente isso há um ano ou mais atrás ... fiz a atualização yum na caixa do CentOS, rodando no hardware da Dell e ele instalou um kernel que não inicializava. A caixa ainda não tinha nada carregado (caso contrário, eu teria sido mais cauteloso). Passei muito tempo brincando com ele e parece que há alguma incompatibilidade entre os kernels mais recentes do CentOS / Linux e a caixa da Dell. Seja muito cauteloso com suas atualizações. Ainda recomendo atualizar, pois é a coisa certa a fazer, mas esteja preparado para se recuperar de um sistema na lixeira!


Ótimo, por acaso é uma caixa da Dell!
31710 John McCollum
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.