dpkg-divert para ficheros de configuracion
Jesus Roncero
Esta tarde he estado investigando la posibilidad de usar dpkg-divert para algo
que parece que no se puede hacer con dpkg-divert.
Os explico: tenemos una serie de servidores con debian los cuales compartiran
una serie de ficheros de configuracion en /etc. La idea es que todos estos
servidores tengan estos ficheros iguales de una manera mas o menos homogenea
en cada momento. Ademas, quisieramos que estos ficheros estuviesen
almacenados en algun sistema de control de versiones de manera que podamos ir
almacenando los cambios que se han realizado a lo largo del tiempo. Lo que se
me habia ocurrido es utilizar dpkg-divert pero con los ficheros de
configuracion, de manera que se crearia un paquete con todos los ficheros que
vamos a tratar, les haria un divert y asi podria tener las configuraciones
syncronizadas dependiendo del paquete que tuviese instalada y evitariamos que
una actualizacion del paquete original que proporciona dicho fichero de
configuracion cambie nuestros cambios (y/o nos pregunte sobre ellos).
Pero parece que esto no funciona con ficheros de configuracion. Alguien sabe
si esto se puede hacer o si dpkg-divert no esta pensado para ficheros de
configuracion? O alguna otra forma de tratar esto con las herramientas de
debian?
O, si sabeis de alguna otra forma con la que tratar este "problema", las
sugerencias serian bienvenidas :)
--
Jesus Roncero
http://roncero.org
--
To UNSUBSCRIBE, email to debian-devel-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sergio Talens-Oliag
> Buenas,
Hola,
> Esta tarde he estado investigando la posibilidad de usar dpkg-divert para algo
> que parece que no se puede hacer con dpkg-divert.
>
> Os explico: tenemos una serie de servidores con debian los cuales compartiran
> una serie de ficheros de configuracion en /etc. La idea es que todos estos
> servidores tengan estos ficheros iguales de una manera mas o menos homogenea
> en cada momento. Ademas, quisieramos que estos ficheros estuviesen
> almacenados en algun sistema de control de versiones de manera que podamos ir
> almacenando los cambios que se han realizado a lo largo del tiempo. Lo que se
> me habia ocurrido es utilizar dpkg-divert pero con los ficheros de
> configuracion, de manera que se crearia un paquete con todos los ficheros que
> vamos a tratar, les haria un divert y asi podria tener las configuraciones
> syncronizadas dependiendo del paquete que tuviese instalada y evitariamos que
> una actualizacion del paquete original que proporciona dicho fichero de
> configuracion cambie nuestros cambios (y/o nos pregunte sobre ellos).
> Pero parece que esto no funciona con ficheros de configuracion. Alguien sabe
> si esto se puede hacer o si dpkg-divert no esta pensado para ficheros de
> configuracion? O alguna otra forma de tratar esto con las herramientas de
> debian?
>
> O, si sabeis de alguna otra forma con la que tratar este "problema", las
> sugerencias serian bienvenidas :)
Yo desarrollé un sistema para mantener versiones propias de ficheros de
configuración que soportasen la actualización de los paquetes para las CDDT
(Custom Debian Distributions Tools), pero como ya no me dedico a eso no llegué
a subir los paquetes a Debian (en la versión antigua de LliureX si que se
utilizaban).
Aunque no creo que te sirvan tal cual, puedes hacer un checkout de:
https://mixinet.net/svn/cddt/trunk/cddt-runtime/
y mirar la carpeta de scripts; los que te pueden interesar son el que se llama
cddt-divert y el que se llama cddt-apt, en la carpeta manpages tienes páginas
de manual que explican como se usan.
La idea básica es que con `cddt-divert` se reemplazan los ficheros de
configuración guardando los ficheros originales (es equivalente al
dpkg-divert, pero usa su propia BBDD y guarda copias de los ficheros de
configuración).
Para que los paquetes puedan actualizarse limpiamente se utiliza el
`cddt-apt`, que quita las versiones «adaptadas» de los ficheros de
configuración antes de actualizar los paquetes, de modo que el sistema se
actualiza como si no se hubiese tocado nada y cuando los paquetes está
configurados volvemos a reemplazar los ficheros de configuración por los
adaptados.
Probablemente el código de los scripts hace más cosas de las que te interesan
por un lado y menos por otro (las configuraciones no se guardan en ningún
sistema de control de versiones), pero igual te ayuda a montarte tu propio
sistema.
Saludos,
Sergio.
--
Sergio Talens-Oliag <s...@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
José L. Redrejo
El mié, 20-02-2008 a las 22:32 +0000, Jesus Roncero escribió:
> Buenas,
>
> Esta tarde he estado investigando la posibilidad de usar dpkg-divert para algo
> que parece que no se puede hacer con dpkg-divert.
>
> Os explico: tenemos una serie de servidores con debian los cuales compartiran
> una serie de ficheros de configuracion en /etc. La idea es que todos estos
> servidores tengan estos ficheros iguales de una manera mas o menos homogenea
> en cada momento. Ademas, quisieramos que estos ficheros estuviesen
> almacenados en algun sistema de control de versiones de manera que podamos ir
> almacenando los cambios que se han realizado a lo largo del tiempo. Lo que se
> me habia ocurrido es utilizar dpkg-divert pero con los ficheros de
> configuracion, de manera que se crearia un paquete con todos los ficheros que
> vamos a tratar, les haria un divert y asi podria tener las configuraciones
> syncronizadas dependiendo del paquete que tuviese instalada y evitariamos que
> una actualizacion del paquete original que proporciona dicho fichero de
> configuracion cambie nuestros cambios (y/o nos pregunte sobre ellos).
> Pero parece que esto no funciona con ficheros de configuracion. Alguien sabe
> si esto se puede hacer o si dpkg-divert no esta pensado para ficheros de
> configuracion? O alguna otra forma de tratar esto con las herramientas de
> debian?
>
> O, si sabeis de alguna otra forma con la que tratar este "problema", las
> sugerencias serian bienvenidas :)
Hola Jesús, te comento que en Extremadura para mantener la configuración
de los servidores de institutos y colegios (varios centenares) usamos
puppet (http://reductivelabs.com) Está en Debian y tiene una
funcionalidad parecida a cfengine pero con un lenguaje para las tareas
mucho más claro y con bastante menos bugs. Si solo quieres asegurar el
contenido de los ficheros es una verdadera chorrada hacerlo con puppet.
Eso garantiza uniformidad en los ficheros o tener grupos de
configuraciones, etc.
Y para el control de versiones en /etc échale un vistazo a la solución
de Debian Edu:
http://wiki.debian.org/DebianEdu/Documentation/Etch/HowTo/Administration#head-90d7542167b5029530d3c0f2c8d3c599334f7e9c
Funciona de maravilla.
Saludos.
José L.
Jesús Roncero
> Hola Jesús, te comento que en Extremadura para mantener la configuración
> de los servidores de institutos y colegios (varios centenares) usamos
> puppet (http://reductivelabs.com) Está en Debian y tiene una
> funcionalidad parecida a cfengine pero con un lenguaje para las tareas
> mucho más claro y con bastante menos bugs. Si solo quieres asegurar el
> contenido de los ficheros es una verdadera chorrada hacerlo con puppet.
> Eso garantiza uniformidad en los ficheros o tener grupos de
> configuraciones, etc.
Si, Habia visto un par de mensajes en debian devel que sugerian el uso de
puppet o de cfengine2 para este tipo de cosas. La verdad es que no tengo
ninguna experiencia con el tema, pero parece interesante y necesito
investigar mas. El problema es que "los que toman las decisiones(tm)" no creo
que esten muy por la labor de integrar una cosa de estas en nuestras
maquinas, ya que la quieren tener lo mas simple posibles. Pero todo se vera.
Nuestra intencion es tener una version personalizada de debian que este
estandarizada, para que la usemos en cada nueva maquina que instalemos. Hay
una serie de configuraciones que estan estandarizadas de una distribucion
anterior (que no es debian) y queremos que cada nueva maquina tenga este
comportamiento. Idealmente, tendriamos un paquete con las configuraciones
especificas si se pudiese hacer esto con dpkg-divert, es mas, suena como lo
ideal a hacer en este caso.
Yo habia pensado en tener todos esos ficheros instalados en algun directorio y
que algun script de despues de la instalacion los copiase en su sitio
correspondiente y que luego, un cronjob nocturno consultase y avisase si
alguno de los ficheros ha sido cambiado, pero no me acaba de gustar esta
aproximacion...
> Y para el control de versiones en /etc échale un vistazo a la solución
> de Debian Edu:
> http://wiki.debian.org/DebianEdu/Documentation/Etch/HowTo/Administration#he
>ad-90d7542167b5029530d3c0f2c8d3c599334f7e9c Funciona de maravilla.
Esto si es interesante :)
Muchas gracias por la respuestas.
--
Jesús Roncero Franco
Jesús Roncero
Buenas
> Yo desarrollé un sistema para mantener versiones propias de ficheros de
> configuración que soportasen la actualización de los paquetes para las CDDT
> (Custom Debian Distributions Tools), pero como ya no me dedico a eso no
> llegué a subir los paquetes a Debian (en la versión antigua de LliureX si
> que se utilizaban).
>
> Aunque no creo que te sirvan tal cual, puedes hacer un checkout de:
>
> https://mixinet.net/svn/cddt/trunk/cddt-runtime/
>
> y mirar la carpeta de scripts; los que te pueden interesar son el que se
> llama cddt-divert y el que se llama cddt-apt, en la carpeta manpages tienes
> páginas de manual que explican como se usan.
El problema que le veo a esto, si lo he entendido bien, en mi configuracion
actual es que aqui no quieren tener una modificacion asi a debian (si hay que
usar cddt-apt para instalar los paquetes), ya que quieren que este todo lo
mas cercano a debian sin cambiar mucho del sistema de paquetes. En cualquier
caso le hago un checkout cuando tenga un hueco y miro a ver como nos puede
ayudar.
Gracias.
--
Jesús Roncero <je...@mxtelecom.com>
System Developer
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com
José L. Redrejo
El jue, 21-02-2008 a las 09:42 +0000, Jesús Roncero escribió:
> On Thursday 21 February 2008 07:52:22 José L. Redrejo Rodríguez wrote:
> > Hola Jesús, te comento que en Extremadura para mantener la configuración
> > de los servidores de institutos y colegios (varios centenares) usamos
> > puppet (http://reductivelabs.com) Está en Debian y tiene una
> > funcionalidad parecida a cfengine pero con un lenguaje para las tareas
> > mucho más claro y con bastante menos bugs. Si solo quieres asegurar el
> > contenido de los ficheros es una verdadera chorrada hacerlo con puppet.
> > Eso garantiza uniformidad en los ficheros o tener grupos de
> > configuraciones, etc.
>
> Si, Habia visto un par de mensajes en debian devel que sugerian el uso de
> puppet o de cfengine2 para este tipo de cosas. La verdad es que no tengo
> ninguna experiencia con el tema, pero parece interesante y necesito
> investigar mas. El problema es que "los que toman las decisiones(tm)" no creo
> que esten muy por la labor de integrar una cosa de estas en nuestras
> maquinas, ya que la quieren tener lo mas simple posibles. Pero todo se vera.
>
> Nuestra intencion es tener una version personalizada de debian que este
> estandarizada, para que la usemos en cada nueva maquina que instalemos. Hay
> una serie de configuraciones que estan estandarizadas de una distribucion
> anterior (que no es debian) y queremos que cada nueva maquina tenga este
> comportamiento. Idealmente, tendriamos un paquete con las configuraciones
> especificas si se pudiese hacer esto con dpkg-divert, es mas, suena como lo
> ideal a hacer en este caso.
El problema con dpkg-divert es que mueves el fichero completo. Eso puede
ser una fuente de fallos en muchos casos. P. ejemplo, en Debian el
fichero dhcpd.conf desde sarge a etch no vale igual, hay algún parámetro
como ddns-update-style que tienes que añadirselo para que arranque el
servidor en etch. Sólo dando el cambiazo no vale. Igual te ocurre con
otros servicios importantes como ldap, bind o squid.
Usando cfengine o puppet lo que haces es añadir las líneas o
configuraciones que quieras en los ficheros, de forma que "respetando"
una parte de la configuración que mete el paquete debian en el fichero
tu añades/modificas las líneas de la tuya, manteniendo la
compatibilidad.
En Debian Edu por ejemplo usan cfengine para hacer la mayor parte de las
"post-configuraciones", pero no lo hacen mediante el modelo
cliente/servidor que es lo que puede asustarle a "los que toman las
decisiones(tm)". El instalador lleva un paquete llamado
debian-edu-config que contiene las reglas de cfengine a aplicar y las
aplica cuando la instalación termina. (En algún caso dan el cambiazo a
fichero completo también). Si quieres puedes dejar cfengine activado
para que regularmente compruebe si las reglas están aplicadas y las
aplique. Todo de forma local, sin conectar a un servidor central. Échale
un vistazo a ese paquete porque creo que hace lo que necesitas pero con
más garantías de éxito que todo con diversion.
En general creo que puedes echarle un vistazo a todo lo relacionado con
las CDD (instala el paquete cdd-doc de sid para tener la documentación
actualizada), porque parece que eso es hacia lo que tiende la idea que
comentas.
Saludos.
Celso González
> Buenas,
>
> Os explico: tenemos una serie de servidores con debian los cuales compartiran
> una serie de ficheros de configuracion en /etc. La idea es que todos estos
> servidores tengan estos ficheros iguales de una manera mas o menos homogenea
> en cada momento. Ademas, quisieramos que estos ficheros estuviesen
> almacenados en algun sistema de control de versiones de manera que podamos ir
> almacenando los cambios que se han realizado a lo largo del tiempo.
Si utilizas un sistema de control de versiones, hay varias recetas para
tener /etc usando svk o git, lo único que tendrías que hacer es
modificar la conf de una máquina y después del commit hacer un update en
el resto, no se si es una alternativa valida para lo que quieres hacer.
--
Celso
http://mitago.net
Sergio Talens-Oliag
Creo que no me he explicado bien, el cddt-apt es un programa que se instala en
el equipo y añade *hooks* sobre *apt* para hacer su gestión de modo
automático, es decir, para instalar sigues utilizando apt-get, aptitude o
synaptic (si instalas cosas con dpkg directamente los hooks no se ejecutan,
por lo que para instalar a mano si deberías ejecutar cddt-dpkg en lugar de
dpkg, que simplemente ejecuta los hooks antes de hacer las cosas).
De hecho, salvo que haya algún BUG (seguro que hay alguno), si instalas el
cddt-runtime pero no hay ningún paquete que lo utilice el sistema es
100 % debian, lo único que cambia es que antes y después de instalar paquetes
se ejecutan scripts que no hacen nada.
En su momento me pareció una buena aproximación al tema de la gestión de
ficheros de configuración de Debian para las custom distributions, ya que como
tú has detectado el dpkg-divert no es una opción aceptable.
La idea básica detrás del sistema es que antes y después de actualizar un
paquete se tengan los ficheros originales de Debian, con lo que las
actualizaciones se harían de modo transparente y sin preguntas, siempre que no
se toque el fichero original y el paquete no tenga bugs de actualización (en
algunos paquetes se ha dado el caso de que el dpkg pregunte por los ficheros
de configuración cuando el usuario no ha tocado nada).
Para adaptar las configuraciones lo que se hace es lanzar scripts después de
instalar o actualizar los paquetes; estos scripts pueden reemplazar los ficheros de
configuración originales por ficheros completos sin más (aproximación más
simple pero menos resistente a cambios de versiones) o ejecutar algún tipo de
operación sobre los ficheros originales para generar un nuevo fichero que
aplique cambios mínimos (generalmente más resistente a actualizaciones,
siempre que no haya cambios importantes en el formato de los ficheros de
configuración).
Si los scripts instalan los ficheros modificados con «cddt-divert» cuando hay
que volver a actualizar el sistema sabe como volver al estado anterior a la
«diversion» y conseguimos el efecto que describía antes.
La idea original es que el sistema se utilice con instalaciones estables y por
tanto se revisen los scripts de «adaptación» para evitar que las cosas queden
en estado inestable, aunque en realidad si lo que vas a hacer es instalar
actualizaciones controladas puedes validar los cambios en un equipo y si hace
falta actualizar el paquete que contenga los scripts de «adaptación» lo haces
antes de actualizar todos los equipos (la gracia es que si actualizas los
paquetes con problemas a la vez que el paquete de «adaptaciones» actualizado
al terminar de ejecutar el «apt» se ejecutan los nuevos scripts y no los
antiguos, con lo que el tema es bastante seguro).
Hay más documentación de como funciona todo en el paquete cddt-doc::
https://mixinet.net/svn/cddt/trunk/cddt-doc/
Jesús Roncero
> Creo que no me he explicado bien, el cddt-apt es un programa que se instala
> en el equipo y añade *hooks* sobre *apt* para hacer su gestión de modo
> automático, es decir, para instalar sigues utilizando apt-get, aptitude o
> synaptic (si instalas cosas con dpkg directamente los hooks no se ejecutan,
> por lo que para instalar a mano si deberías ejecutar cddt-dpkg en lugar de
> dpkg, que simplemente ejecuta los hooks antes de hacer las cosas).
Ah, entiendo. Gracias, le echare un vistazo, aunque el que solo sean hooks
para apt si veo que pueda ser un problema cuando alguien haga algo
manualmente con dpkg. En cualquier caso es interesante y lo pongo en la lista
para mirarlo con mas detenimiento.
Gracias.
--
Jesús Roncero Franco
Jesús Roncero
> En general creo que puedes echarle un vistazo a todo lo relacionado con
> las CDD (instala el paquete cdd-doc de sid para tener la documentación
> actualizada), porque parece que eso es hacia lo que tiende la idea que
> comentas.
Gracias, lo tengo en la lista de documentacion que tengo que mirar. Lo de la
configuracion de cfengine parece interesante.
--
Jesús Roncero Franco
Jesús Roncero
> Si utilizas un sistema de control de versiones, hay varias recetas para
> tener /etc usando svk o git, lo único que tendrías que hacer es
> modificar la conf de una máquina y después del commit hacer un update en
> el resto, no se si es una alternativa valida para lo que quieres hacer.
Si, he visto lo que usan debian-edu (con svk) y tambien he visto etckeeper,
pero no estoy muy seguro como afectaria cambiar, por ejemplo, /etc/shadow de
esta manera y si generaria algun tipo de problema de seguridad...
Javier Fernández-Sanguino Peña
> La idea básica detrás del sistema es que antes y después de actualizar un
> paquete se tengan los ficheros originales de Debian, con lo que las
> actualizaciones se harían de modo transparente y sin preguntas, siempre que no
> se toque el fichero original y el paquete no tenga bugs de actualización (en
> algunos paquetes se ha dado el caso de que el dpkg pregunte por los ficheros
> de configuración cuando el usuario no ha tocado nada).
Esto puede ser un problema porque algunos scripts de postinst miran los
contenidos de los ficheros de configuración para avisarte de problemas
(variables que no se utilizan, errores, etc.) y si haces esto y tus ficheros
de configuración están mal no se te va a avisar.
Un saludo
Javier
Sergio Talens-Oliag
Correcto, la idea es los paquetes de «adaptación» se encarguen de garantizar
que los ficheros son válidos y si no lo hacen tienen un Bug, igual que sucede
con los paquetes normales.
Si se trabaja pensando en distribuciones «estables» el modelo es bastante
fácil de mantener, sobre todo si no se modifican a mano los ficheros de
configuración «adaptados», que es el objetivo de este tipo de sistemas.
En cualquier caso la idea original era conseguir que la necesidad de este tipo
de adaptaciones sea mínima y que cuando se hagan sea modificando los ficheros
obtenidos al instalar los paquetes de Debian originales, empleando
herramientas como cfengine o algún lenguaje de scripting que permita validar
de algún modo las modificaciones realizadas.