Gerenciando a configuração via RPMs?

Question

Eu preciso fornecer alguma personalização de configuração para vários servidores em nossa pequena rede de departamento. Atualmente, estamos usando o RHEL5 e, como não quero repetir o trabalho, gostaria de criar RPMs com essa configuração e enviá-los para o nosso RHN.

Agora, o problema: supondo que eu queira distribuir a configuração do NTP via /etc/ntp.conf . Infelizmente, não há /etc/ntp.d/ para colocar meus arquivos, então eu teria que substituir o ntp.conf pelo meu RPM. Como faço isso corretamente, ou seja, sem perder essa configuração quando ntp é atualizado e também sem possíveis conflitos de arquivos de configuração?

    

Answer 1

Vá com a solução de David de usar o fantoche. Realmente.

No entanto, se você está determinado, o que você pode fazer é criar um pacote rassie-ntp-conf que contenha "/etc/ntp.conf.rassie". No arquivo de especificação, você precisará de um %post que copie sua configuração sobre a configuração padrão e também um " %triggerin -- ntp-server " que faça o mesmo. Dessa forma, se uma atualização posterior sobrescrever a configuração, o gatilho fará a cópia de volta. Talvez faça alguma coisa em /etc/cron.daily para fazer o mesmo para ter certeza ... Provavelmente, todos esses scripts devem ter um service ntpd condrestart após o cp também.

Esse é o básico. Se você quiser fazer isso para mais pacotes, você pode construir um script padrão que corre através de / etc / rassie / para encontrar configurações para copiar em / etc e fazer com que as coisas% post e% triggerin executem isso.

Mas, realmente, ignore isso e use fantoches ou chefes ou cfengine ... Esse tipo de esquema de "empurrar a configuração para fora via RPM" é repleto de problemas sutis decorrentes do problema fundamental de que o RPM não foi projetado para ter dois diferentes pacotes lutam em um único arquivo. Difícil de testar, difícil de depurar, exatamente o tipo de solução inteligente que fará com que você mais tarde deseje ter ido com bonecos em primeiro lugar.

    

Answer 2

Posso sugerir uma solução alternativa? Você pode achar que uma ferramenta de gerenciamento de configuração como Puppet ou Cfengine2 faz o que você quer. Você escreve arquivos de manifesto que descrevem como você deseja que um sistema apareça e ele desaparece e altera o sistema para que fique assim. Observe a distinção importante que você está descrevendo como o sistema deve parecer, e não como você muda o sistema. Um exemplo para o ntp pode ser:

class ntp {
   package {"ntpd":
       ensure => latest,
   }
   file { "/etc/ntp/ntp.conf":
       source => "puppet:///ntp/ntp.conf",
       owner => "root",
       group => "root",
       mode => 644,
       require => Package["ntpd"],
   }
   service { "ntpd":
       ensure => running,
       enable => true,
       subscribe => File["/etc/ntp/ntp.conf"],
   }
}

Quando você incluir essa classe em um determinado nó, você instalará o pacote ntpd, copiará o arquivo para o servidor e verificará se o daemon está sendo executado. Se o puppet fizer qualquer alteração no ntp.conf, ele irá reiniciar o daemon ntp (graças à linha de assinatura).

Como isso resolve seus problemas? Bem, quando uma nova versão do ntp é instalada, se o pacote sobrescrever o arquivo de configuração, o fantoche copiará o antigo de volta. Se houver diferenças, ele exibirá um diff à medida que for alterado, para que você possa ver quais alterações foram feitas, para que você possa notar quaisquer diferenças e atualizar sua versão central, caso deseje essas alterações.

    

Answer 3

Independentemente de como você decide empurrar as mudanças, se você precisar modificar o ntp.conf (ou qualquer arquivo de configuração, na verdade) e não quiser substituir o arquivo por atacado, dê uma olhada no Augeas ( link . Há um pouco de curva de aprendizado, mas elimina muita complexidade da análise / edição de arquivos.

    

Answer 4

Acho que o Puppet ou o CFEngine é o caminho a percorrer a longo prazo. Mas como um primeiro passo que facilita a implementação de um sistema de controle de versão, como o subversion ou o git, deve funcionar. Você desejará manter seu histórico de alterações de arquivos de configuração, mesmo sob Puppet e CFEngine.

    

Answer 5

Eu tentei usar apenas rpms para. Somente quando seus arquivos de configuração são muito simples, é possível.

A melhor abordagem, mas não é simples implementar, é usar ferramentas como o fantoche e o cfengine, como todos sugeriram.