Preciso fornecer alguma personalização de configuração para vários servidores em nossa pequena rede de departamentos. Estamos usando o RHEL5 atualmente e como não quero repetir o trabalho, gostaria de criar RPMs com essa configuração e carregá-los em nosso RHN.
Agora o problema: supondo que eu queira distribuir a configuração NTP via /etc/ntp.conf. Infelizmente, não há onde /etc/ntp.d/colocar meus arquivos, então eu teria que sobrescrevê-los ntp.confcom meu RPM. Como faço isso corretamente, ou seja, sem perder aquela configuração ao ntpatualizar e também sem possíveis conflitos nos arquivos de configuração?
Responder1
Vá com a solução de David de usar fantoches. Realmente.
No entanto, se você estiver determinado, o que você pode fazer é criar um pacote rassie-ntp-conf que contenha "/etc/ntp.conf.rassie". No arquivo de especificações, você precisará de um %postque copie sua configuração sobre a configuração padrão e também de um " %triggerin -- ntp-server" que faça o mesmo. Dessa forma, se uma atualização posterior substituir a configuração, o gatilho irá copiá-la novamente. Talvez coloque algo em /etc/cron.daily para fazer o mesmo para ter certeza ... Provavelmente será necessário que todos esses scripts sejam executados service ntpd condrestartapós o cp também.
Esse é o básico. Se você quiser fazer isso para mais pacotes, você pode, em vez disso, construir um script padrão que seja executado em /etc/rassie/ para encontrar configurações para copiar em /etc e fazer com que o material %post e %triggerin seja executado.
Mas, realmente, ignore isso e use puppet ou Chef ou cfengine... Esse tipo de esquema de "empurrar a configuração via RPM" está repleto de problemas sutis decorrentes do problema fundamental de que o RPM não foi projetado para ter dois pacotes diferentes brigando. um único arquivo. Difícil de testar, difícil de depurar, exatamente o tipo de solução inteligente que mais tarde fará você desejar ter optado pelo fantoche.
Responder2
Posso sugerir uma solução alternativa? Você pode descobrir que uma ferramenta de gerenciamento de configuração como Puppet ou Cfengine2 faz o que você deseja. Você escreve arquivos de manifesto que descrevem como você deseja que um sistema tenha a aparência e ele desaparece e altera o sistema para que fique assim. Observe a importante distinção de que você está descrevendo a aparência do sistema, e não como você altera o sistema. Um exemplo para 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"],
}
}
Ao incluir esta classe em um nó específico, você instalará o pacote ntpd, copiará seu arquivo para o servidor e verificará se o daemon está em execução. Se o puppet fizer alguma alteração no ntp.conf, ele reiniciará o daemon ntp (graças à linha de assinatura).
Como isso resolve seus problemas? Bem, quando uma nova versão do ntp for instalada, se o pacote substituir o arquivo de configuração, o puppet copiará o antigo de volta. Se houver alguma diferença, ele exibirá uma diferença à medida que for alterando, para que você possa ver quais alterações foram feitas, para que você possa notar quaisquer diferenças e atualizar sua versão central se desejar essas alterações.
Responder3
Independentemente de como você decidir enviar as alterações, se precisar modificar o ntp.conf (ou qualquer arquivo de configuração, na verdade) e não quiser substituir o arquivo no atacado, dê uma olhada em Augeas (http://augeas.net). Há uma pequena curva de aprendizado, mas elimina grande parte da complexidade de análise/edição de arquivos.
Responder4
Eu tentei lidar usando apenas rpms para. Somente quando seus arquivos de configuração são muito simples é possível.
A melhor abordagem, mas não é tão simples de implementar, é usar ferramentas como puppet e cfengine, como todos sugeriram.