Wie kann ich mit Git oder einem anderen VCS die Versionskontrolle für Serverkonfigurationsdateien durchführen, die zur Anwendungslaufzeit geändert werden?

Question

Ich betreibe einen Minecraft-Server (craftbukkit) und habe mehrere andere Administratoren, die Zugriff auf die Änderung von Serverkonfigurationsdateien haben möchten. Es ist wichtig, dass ich alle ihre Änderungen verfolge, daher scheint Git natürlich eine gute Wahl zu sein.

Bitte beachten Sie, dass diese Frage viele Situationen betreffen kann.es ist nicht spezifisch für Minecraft.

Es gibt mehrere Tutorials zur Verwendung von Git zur Verwaltung von Websites. Die gängigsten Lösungen scheinen die Verwendung vonPost-Receive-Hookum einen Checkout-Vorgang für das Webverzeichnis auszuführen. In meiner Situation wirft dies jedoch einige Probleme auf.

Erstens müssten Administratoren einige Dateien bearbeitenwerden zur Laufzeit vom Server geändert. Ich gehe davon aus, dass dies Git verwirren würde, wenn ich das Serververzeichnis selbst zum Repository machen würde. Mit der Post-Receive-Checkout-Lösung wäre dies weniger problematisch, wenn ich richtig liege (ich lerne Git noch).

Ich müsste auch Änderungen, die vom Server vorgenommen wurden, in das Repository übertragen, damit Administratoren diese Änderungen in ihre lokalen Repositorys herunterladen können. Ich habe Lösungen gesehen, die Folgendes verwenden:inotifywaitaber diese scheinen alle nur einzelne Dateiänderungen zu berücksichtigen. Mein Server hat 50-80 Konfigurationsdateien, die ich verfolgen und automatisch festschreiben müsste, wenn die Serverlaufzeit sie ändert. Was wäre der beste Weg, damit umzugehen?

Beachten Sie, dass die Verwendung von Git keine Voraussetzung ist. Mir gefällt einfach, was ich bisher davon verwendet habe. Wenn es ein besseres Tool für die Aufgabe gibt, bin ich bereit, es zu verwenden, solange es benutzerfreundlich ist. Beachten Sie, dass meine Serveradministratoren weder Programmierer noch Linux-Poweruser sind, daher ist Benutzerfreundlichkeit hilfreich.

Ich habe dies ursprünglich auf StackOverflow gepostet, mir wurde aber gesagt, dass es hier besser geeignet sei.

Answer 1

Dies ist keine vollständige Antwort, aber hoffentlich einige nützliche Gedanken:

inotifywaitfunktioniert problemlos mit mehreren Dateien und kann rekursiv Überwachungspunkte für Verzeichnisse setzen. Ich kann beispielsweise Folgendes ausführen:

inotifywait -m -r -e close_write /etc

Und erhalten Sie nach dem Bearbeiten das folgende Protokoll /etc/passwd:/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

Sie könnten dies sehr einfach in ein Skript einbauen, das bei jedem close_writeEreignis die Datei in das lokale Repository überträgt und die Änderungen an einen Remote-Server sendet.

Beachten Sie auch, dassinkronist ein praktisches Tool zum Automatisieren dieser Art von inotify-basiertem Workflow (würde aber die Art der Lösung nicht wesentlich verändern).

Sie werden auf Schwierigkeiten stoßen, wenn Ihre Administratoren dieselben Dateien bearbeiten, die zur Laufzeit vom Server aktualisiert werden. Dies bedeutet, dass Sie auf dem Server eine Art automatische Konfliktlösung einrichten müssen, was unweigerlich zum Verlust einiger Informationen führen wird (alsoersichtlichVerlust, zumindest können Sie offensichtlich widersprüchliche Änderungen in zwei unterschiedlichen Zweigen des Repository beibehalten, aber der Server bekommt nur einen Zweig zu sehen).

Ich glaube nicht, dass Teile dieses Problems oder dieser Lösung spezifisch für Git sind. Diese Probleme treten bei jeder Art von verteilter, asynchron synchronisierter gemeinsamer Dateiverwaltung auf.

Answer 2

Was ich in ähnlichen Situationen getan habe, ist, die Live-Konfiguration zu einem Repository zu machen (ich verwende normalerweise Bazaar) und einen Cronjob zu schreiben, um alle Änderungen automatisch zu übernehmen. Die Live-Konfiguration als VCS-Repository zu haben, sollte kein Problem sein – der einzige Unterschied ist das .gitVerzeichnis, das in den meisten Fällen einfach ignoriert werden sollte. Das Intervall des Cronjobs kann beliebig fein sein. Jede Stunde war für meine Situationen gut genug, aber es könnte auch alle 5 Minuten oder sogar 1 Minute sein, falls nötig.

Answer 3

Es gibt mehrere Tutorials zur Verwendung von Git zur Verwaltung von Websites. Die gängigsten Lösungen scheinen die Verwendung vonPost-Receive-Hookum einen Checkout-Vorgang für das Webverzeichnis auszuführen.

Die Konfigurationsdateien finden Sie unterusw.Keeper:

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

Erstens müssten Administratoren einige Dateien bearbeitenwerden zur Laufzeit vom Server geändert.

Kein Problem.

Außerdem müsste ich die vom Server vorgenommenen Änderungen in das Repository übertragen, damit die Administratoren diese Änderungen in ihre lokalen Repositorys abrufen können.

Wird standardmäßig etckeepertäglich als Cron-Job ausgeführt:

/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

Wenn Sie auch in das Remote-Repository pushen möchten, bearbeiten Sie die obige Datei wie folgt:

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

Wenn tägliche oder sogar minütliche Intervalle nicht ausreichen,BeobachterSie können Ihre Konfigurationsdateien sofort nach der Änderung festschreiben:

/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

Versuche es.