Necesito proporcionar cierta personalización de la configuración a varios servidores en la red de nuestro pequeño departamento. Actualmente estamos usando RHEL5 y como no quiero repetir el trabajo, me gustaría crear RPM con esa configuración y cargarlos en nuestro RHN.
Ahora el problema: suponiendo que quiero distribuir la configuración NTP a través de /etc/ntp.conf. Lamentablemente, no hay dónde /etc/ntp.d/colocar mis archivos, por lo que tendría que sobrescribirlos ntp.confcon mi RPM. ¿Cómo lo hago correctamente, es decir, sin perder esa configuración cuando ntpse actualiza y también sin posibles conflictos con los archivos de configuración?
Respuesta1
Opte por la solución de David de utilizar títeres. En realidad.
Sin embargo, si está decidido, lo que puede hacer es crear un paquete rassie-ntp-conf que contenga "/etc/ntp.conf.rassie". En el archivo de especificaciones, necesitará un %postarchivo que copie su configuración sobre la configuración predeterminada y también un " %triggerin -- ntp-server" que haga lo mismo. De esa manera, si una actualización posterior sobrescribe la configuración, el activador la copiará nuevamente. Tal vez coloque algo en /etc/cron.daily para hacer lo mismo y estar realmente seguro... Probablemente también necesite que todos esos scripts se ejecuten service ntpd condrestartdespués del cp.
Eso es lo básico. Si desea hacerlo para más paquetes, puede crear un script estándar que se ejecute a través de /etc/rassie/ para encontrar configuraciones para copiar en /etc y hacer que %post y %triggerin las ejecuten en su lugar.
Pero, en realidad, ignórelo y use Puppet o Chef o cfengine... Este tipo de esquema de "expulsar la configuración a través de RPM" está plagado de problemas sutiles que surgen del problema fundamental de que RPM no está diseñado para que dos paquetes diferentes peleen por él. un solo archivo. Difícil de probar, difícil de depurar, exactamente el tipo de solución inteligente que más tarde te hará desear haber elegido Puppet en primer lugar.
Respuesta2
¿Puedo sugerir una solución alternativa? Es posible que descubra que una herramienta de gestión de configuración como Puppet o Cfengine2 hace lo que desea. Escribe archivos de manifiesto que describen cómo desea que se vea un sistema y desaparece y cambia el sistema para que se vea así. Observe la distinción importante de que está describiendo cómo debería verse el sistema, no cómo cambiarlo. Un ejemplo de ntp podría 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"],
}
}
Cuando incluya esta clase en un nodo particular, instalará el paquete ntpd, copiará su archivo al servidor y se asegurará de que el demonio se esté ejecutando. Si Puppet realiza algún cambio en ntp.conf, reiniciará el demonio ntp (gracias a la línea de suscripción).
¿Cómo resuelve esto tus problemas? Bueno, cuando se instala una nueva versión de ntp, si el paquete sobrescribe el archivo de configuración, Puppet copiará el anterior nuevamente. Si hay alguna diferencia, mostrará una diferencia a medida que la cambie, para que pueda ver qué cambios se han realizado, para que pueda notar cualquier diferencia y actualizar su versión central si desea esos cambios.
Respuesta3
Independientemente de cómo decida implementar los cambios, si necesita modificar ntp.conf (o cualquier archivo de configuración, en realidad) y no desea reemplazar el archivo por completo, eche un vistazo a Augeas (http://augeas.net). Hay una pequeña curva de aprendizaje, pero elimina gran parte de la complejidad de analizar/editar archivos.
Respuesta4
Intenté manejar el uso solo de rpm para. Sólo es posible cuando tus archivos de configuración son muy simples.
El mejor enfoque, aunque no es demasiado sencillo de implementar, es utilizar herramientas como Puppet y cfengine, como todos sugirieron.