Existe uma grande diferença entre o CentOS 6.4 e 6.2 e devo aumentar / diminuir a qualidade?


9

Temos dois servidores web gerenciados separados. Um deles está executando o CentOS 6.2 e é usado como um ambiente de produção para vários sites. O segundo executa o CentOS 6.4 e hospeda alguns aplicativos internos, como o wiki, o gitlab e o rastreador de problemas.

Eu também gostaria de usar o secundário como um ambiente de preparação para os sites que desenvolvemos, para testar antes que eles entrem em produção. Idealmente, os dois ambientes devem ter uma configuração idêntica em termos de SO.

Minhas opções parecem ser;

  1. Atualize o live box para 6.4 - Atualmente, temos sites clientes lá, então isso parece um pouco arriscado.
  2. Faça o downgrade da caixa secundária para 6.2 - estou nervoso por atrapalhar as coisas que temos atualmente, não quero reinstalar as ferramentas de desenvolvimento usadas diariamente.
  3. Ignore a diferença e espere que não seja grande coisa.

A opção 3 é tentadora, mas como não consigo encontrar realmente as diferenças entre as duas versões, não sei se é ou não sensato, alguém pode aconselhar por favor?

Respostas:


20

Essa deve ser uma das coisas mais incompreendidas sobre o RHEL / CentOS (as duas são efetivamente intercambiáveis ​​para os fins deste post).

CentOS é um sistema operacional. CentOS 6 é uma versão desse SO; é muito diferente do CentOS 5. O CentOS 6.1 não é uma versão do SO, é apenas um nível de patch do CentOS 6. Para entender isso, você precisa entender a política de empacotamento e correção da Red Hat.

A Red Hat escolhe a versão de qualquer ferramenta que eles usarão quando iniciarem uma versão do RHEL. Para o RHEL 6, isso incluía o Apache 2.2.15, o kernel 2.6.32, php 5.3.3 e assim por diante. Pelo resto da vida do RHEL6, eles não serão atualizados; A Red Hat fará o backport de todos os patches necessários (e ocasionalmente, como dsumsky aponta, melhorias que são desejáveis) para a versão que eles escolheram. Isso significa que você estará executando um software cujo número de versão sugere vulnerabilidade a certas explorações conhecidas, mas que foi corrigido para evitar essas vulnerabilidades (caso você queira uma referência autorizada, a Red Hat explique isso com suas próprias palavras aqui ) . É incrível quantos auditores de segurança não entendem isso, alguns deles mesmo depois disso '

Essa política de correção faz com que muitas pessoas publiquem no SF perguntando como podem obter o PHP mais recente em sua caixa C6, mas também causa grande estabilidade.

Agora, versionando: em um determinado dia, a Red Hat efetivamente desenha uma linha através do estado atual do patch do RHEL6 e declara que é (digamos) RHEL6.4. Eles fazem ISOs disso, mas não é realmente uma versão do RHEL 6, é apenas o RHEL 6 no estado de atualização naquele dia. Se você deseja uma caixa RHEL totalmente atualizada, é mais rápido instalar a partir dos ISOs e patch do RHEL 6.4 do que instalar a partir dos ISOs e do patch RHEL 6.0, mas você acaba com a mesma coisa - RHEL 6.4

O CentOS, seguindo o upstream como eles, fazem o mesmo.

Isso significa que, desde que você não tenha instalado nada fora da pista (por assim dizer), e que você tenha feito backup com segurança de todos os seus arquivos de configuração, você pode passar do C6.2 para o C6.4 sem nenhum grande medo.

Além disso, não só não é uma má idéia atualizar, como é muito boa. Neste ponto, C6.2 está efetivamente no final da vida útil. Ele não está recebendo correções, não é suportável e não é suportado, porque se você trouxer uma caixa C6.2 para o patch, é C6.4. Não há como executar uma caixa C6.2 totalmente corrigida sem que ela seja C6.4 1 .

1 Isso não é inteiramente verdade; você pode se inclinar para trás para não atualizar o redhat-releasepacote, que controla o arquivo que determina a versão, mas a única razão para fazer isso é se você estiver executando algum software comercial insano que insiste em uma versão específica do RHEL / CentOS. Se você estiver executando uma coisa dessas, livre-se dela. É inadequado para o propósito e escrito (ou, mais provavelmente, comercializado) por idiotas.


4
tl; dr: sysadmin ruim, por que você não está mantendo seus retalhos atualizados ?! :-)
ThatGraemeGuy 2/13

@ThatGraemeGuy, isso me fez rir :) Eu gostaria que sempre fosse assim tão fácil.
Wzzrd

1
Verdade. Alguns de nós têm a sorte de trabalhar em ambientes onde as coisas são bem arquitetadas, para que o tempo de atividade do serviço seja importante e seja principalmente independente do tempo de atividade do sistema individual. Quando você passa tempo suficiente em um ambiente como esse, é fácil esquecer que nem todo mundo tem esse luxo.
precisa saber é o seguinte

Ótima resposta informativa. Ótima explicação. Não posso dizer quantas vezes me deparei com esse mal-entendido. Vou marcar como favorito, compartilhá-lo e imprimir um pôster gigante de 4'x6 'e colá-lo na parede do escritório para que todos vejam.
Stefan Lasiewski

1
@StefanLasiewski obrigado - eu aprecio muito seus gentis comentários. Além disso, sinta-se à vontade para me enviar uma cópia do pôster!
MadHatter

0

Em relação ao RHEL / CentOS 6.3 , esta atualização trouxe principalmente melhorias de virtualização, como mais CPUs ou memória para convidados ou ferramenta virt-p2v para migrar máquinas físicas para máquinas virtuais. Caso contrário, não conheço nenhuma alteração importante que possa afetar os aplicativos instalados. Gostaria apenas de verificar previamente os pacotes atualizados que estão instalados no servidor e os drivers do kernel atualizados, obrigatórios para a execução do servidor. Em geral, essas atualizações incluem apenas correções de bugs ou segurança.

Em relação ao RHEL / CentOS 6.4 , estou ciente de algumas alterações importantes que oferecem suporte total a NFS paralelo ou drivers atualizados para executar melhor os convidados RHEL6.4 nos hipervisores Hyper-V / ESXi. Caso contrário, eu verificaria todos os pacotes / drivers atualizados do kernel, como na versão 6.3.

Na minha opinião, eu tentaria atualizar o sistema para a versão mais recente 6.4. Eu não esperaria nenhum desastre ...


1
//, você teve a chance de ler a resposta de @ MadHatter?
Nathan Basanese
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.