¿Cómo puedo controlar las versiones de los archivos de configuración del servidor que se modifican en tiempo de ejecución de la aplicación, usando git u otro VCS?

Question

Estoy ejecutando un servidor de Minecraft (craftbukkit) y tengo varios otros administradores que desean acceder para modificar los archivos de configuración del servidor. Es importante realizar un seguimiento de todos sus cambios, por lo que, naturalmente, git parece una buena opción.

Tenga en cuenta que esta pregunta podría referirse a muchas situaciones,No es específico de Minecraft.

Existen varios tutoriales sobre el uso de git para administrar sitios web. La solución más común parece ser utilizar elgancho posterior a la recepciónpara ejecutar una operación de pago en el directorio web. Sin embargo, en mi situación esto plantea algunos problemas.

Primero, algunos archivos que los administradores tendrían que editarson cambiados por el servidor en tiempo de ejecución. Supongo que esto confundiría a git si convirtiera el directorio del servidor en el repositorio. Usar la solución de pago posterior a la recepción, esto sería menos problemático, si estoy en lo cierto (todavía estoy aprendiendo git).

También necesitaría que los cambios realizados por el servidor se envíen al repositorio, para que los administradores puedan recuperar esos cambios en sus repositorios locales. He visto soluciones usandoinotificaresperarpero todos estos parecen tener en cuenta sólo los cambios de archivos individuales. Mi servidor tiene entre 50 y 80 archivos de configuración que necesitaría rastrear y confirmar automáticamente cuando el tiempo de ejecución del servidor los cambie. ¿Cuál sería la mejor manera de manejar esto?

Tenga en cuenta que usar git no es un requisito. Simplemente me gusta lo que he usado hasta ahora. Si existe una herramienta mejor para el trabajo, estoy abierto a utilizarla, siempre que sea fácil de usar. Tenga en cuenta que los administradores de mi servidor no son programadores ni usuarios avanzados de Linux, por lo que la facilidad de uso ayuda.

Originalmente publiqué esto en StackOverflow, pero me dijeron que era más adecuado para aquí.

Answer 1

Esta no es una respuesta completa, pero con suerte algunas ideas útiles:

inotificaresperarfuncionará felizmente con múltiples archivos y puede establecer recursivamente puntos de vigilancia en directorios. Por ejemplo, puedo ejecutar:

inotifywait -m -r -e close_write /etc

Y obtenga el siguiente registro después de editar /etc/passwdy /etc/postfix/main.cf:

/etc/ CLOSE_WRITE,CLOSE .passwd.swpx
/etc/ CLOSE_WRITE,CLOSE .passwd.swp
/etc/ CLOSE_WRITE,CLOSE 4913
/etc/ CLOSE_WRITE,CLOSE passwd
/etc/ CLOSE_WRITE,CLOSE .passwd.swp
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swx
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swp
/etc/postfix/ CLOSE_WRITE,CLOSE 4913
/etc/postfix/ CLOSE_WRITE,CLOSE main.cf
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swp

Podrías convertir esto muy fácilmente en un script que, en cada close_writeevento, enviaría el archivo al repositorio local y enviaría los cambios a un servidor remoto.

También tenga en cuenta queincrones una herramienta ingeniosa para automatizar este tipo de flujo de trabajo basado en inotify (pero no cambiaría sustancialmente la naturaleza de la solución).

Te encontrarás con dificultades si tus administradores editan los mismos archivos que el servidor actualiza en tiempo de ejecución. Esto sugiere que tendrá que configurar algún tipo de resolución automática de conflictos en el servidor, lo que invariablemente resultará en la pérdida de información (bueno,aparentepérdida, al menos, obviamente puede preservar los cambios conflictivos en dos ramas distintas del repositorio, pero el servidor solo puede ver una rama).

No creo que ninguna parte de este problema o solución sea específica de git. Te encontrarás con estos problemas con cualquier tipo de mantenimiento compartido de archivos distribuido y sincronizado de forma asincrónica.

Answer 2

Lo que hice en situaciones similares fue convertir la configuración en vivo en un repositorio (tiendo a usar Bazaar) y escribir un cronjob para confirmar automáticamente cualquier cambio. Tener la configuración en vivo de un repositorio VCS no debería ser un problema; la única diferencia es el .gitdirectorio, que debería ignorarse en la mayoría de los casos. El intervalo del cronjob sería cualquier granularidad con la que esté satisfecho. Cada hora ha sido suficiente para mis situaciones, pero podría ser cada 5 minutos, o incluso 1 minuto si fuera necesario.

Answer 3

Existen varios tutoriales sobre el uso de git para administrar sitios web. La solución más común parece ser utilizar elgancho posterior a la recepciónpara ejecutar una operación de pago en el directorio web.

Para los archivos de configuración, eche un vistazo aetc guardián:

Name       : etckeeper
Arch       : noarch
Version    : 0.63
Release    : 1.el5
Size       : 36 k
Repo       : epel
Summary    : Store /etc in a SCM system (git, mercurial, bzr or darcs)
URL        : http://kitenet.net/~joey/code/etckeeper/
License    : GPLv2+
Description: The etckeeper program is a tool to let /etc be stored in a git,
           : mercurial, bzr or darcs repository. It hooks into yum to automatically
           : commit changes made to /etc during package upgrades. It tracks file
           : metadata that version control systems do not normally support, but that
           : is important for /etc, such as the permissions of /etc/shadow. It's
           : quite modular and configurable, while also being simple to use if you
           : understand the basics of working with version control.
           : 
           : The default backend is git, if want to use a another backend please
           : install the appropriate tool (mercurial, darcs or bzr).
           : To use bzr as backend, please also install the etckeeper-bzr package.
           : 
           : To start using the package please read /usr/share/doc/etckeeper-0.63/README

Primero, algunos archivos que los administradores tendrían que editarson cambiados por el servidor en tiempo de ejecución.

Ningún problema.

También necesitaría que los cambios realizados por el servidor se envíen al repositorio, para que los administradores puedan recuperar esos cambios en sus repositorios locales.

De forma predeterminada, etckeeperse ejecuta diariamente como una tarea cron:

/etc/cron.daily/etckeeper

#!/bin/sh
set -e
if [ -x /usr/bin/etckeeper ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
    . /etc/etckeeper/etckeeper.conf
    if [ "$AVOID_DAILY_AUTOCOMMITS" != "1" ]; then
        # avoid autocommit if an install run is in progress
        lockfile=/var/cache/etckeeper/packagelist.pre-install
        if [ -e "$pe" ] && [ -n "$(find "$lockfile" -mtime +1)" ]; then
            rm -f "$lockfile" # stale
        fi
        if [ ! -e "$lockfile" ]; then
            AVOID_SPECIAL_FILE_WARNING=1
            export AVOID_SPECIAL_FILE_WARNING
            if etckeeper unclean; then
                etckeeper commit "daily autocommit" >/dev/null
            fi
        fi
    fi
fi

Si también desea ingresar al repositorio remoto, edite el archivo anterior como se muestra a continuación:

        if etckeeper unclean; then
            etckeeper commit "daily autocommit" >/dev/null
            cd /etc && git push origin master
        fi

Si un intervalo diario o incluso de un minuto no es suficiente,vigilantePuede enviar sus archivos de configuración inmediatamente después de cambiar:

/etc/watcher.ini

[DEFAULT]
logfile=/tmp/watcher.log
pidfile=/tmp/watcher.pid
[job1]
watch=/etc
events=create,delete,write_close
recursive=true
autoadd=true
command=cd /etc && etckeeper commit "daily autocommit" >/dev/null && git push origin master

Darle una oportunidad.