YUM, “patchlevel” e a rua DTAP no redhat / centos

Question

Existe uma maneira de atualizar o yum para um determinado nível de patch?

Sempre prometo aos meus desenvolvedores que os servidores entre Dev, Test, Acc e Prod são os mesmos com versões de software. Mas quando você usa o yum através da rede redhat, ele apenas atualizará para as versões mais recentes, independentemente.

o problema chega quando você rola para um servidor além de dev ou teste. É claro que você pode excluir pacotes importantes desse processo de atualização. Mas todos os outros pacotes ainda serão atualizados para uma versão mais nova se houver uma nova versão disponível desde a última atualização. Desta forma, seus servidores não serão exatamente os mesmos.

Existe uma maneira (via yum) para ter certeza de que você obterá exatamente a mesma configuração de pacote que os outros servidores na sua rua DTAP.

    

Answer 1

Esta é a beleza do gerenciamento de configuração ... Por exemplo: usando Puppet, eu poderia ensure => latest ou mesmo ensure => '1.2.2-7.el6'

Por favor, dê um exemplo dos pacotes específicos cujas versões você deseja controlar?

Eu pergunto porque este é o Red Hat / CentOS, e uma tremenda quantidade de esforço é feita para manter as versões principais dos pacotes compatíveis entre pequenas revisões ao longo da vida útil do produto servidor. Na realidade, não importa se você está executando package-0.17-39.el6 ou package-0.17-43.el6 . Sem mencionar as correções de bug e segurança que são constantemente portadas ...

Então, em alguns aspectos, meus servidores de desenvolvimento, teste e produção são parecidos apenas porque são a mesma revisão do RHEL / CentOS e possuem os mesmos pacotes. Mas as versões secundárias podem mudar, dependendo das circunstâncias, como data de instalação, programação de patches, requisitos de disponibilidade / disponibilidade, plataforma de hardware, etc.

Meu conselho:

• fixe as versões específicas dos pacotes que importam para você (pelo yum, pelo repo local ou pelo gerenciamento de configuração).
• desativar as atualizações automáticas.
• desenvolva um cronograma de patches que englobe todo o seu ambiente.
• revise seu processo de criação.
• implementa o gerenciamento de configurações, é claro.

Answer 2

Fazemos isso com espelhos locais de repositórios do CentOS (+ todos os outros softwares que usamos) e configuramos todos os nossos servidores por meio de sistemas de gerenciamento de configuração para usar apenas repositórios de espelhos internos.

Dessa forma, podemos controlar a hora exata em que os patches aparecem no repositório.
Os servidores recém-instalados terão os mesmos pacotes, assim como os sistemas já instalados (durante o kickstart, já apontamos para nossos espelhos internos). Temos diferentes servidores de repositórios para controle de qualidade e produção. Dessa forma, também podemos testar os patches primeiro nos servidores de controle de qualidade e, em seguida, sincronizar esse repositório com o repositório de produção.

Pode haver sistemas mais complexos para gerenciar isso (caminhada espacial?), mas essa solução simples funcionou bem para nós.