etckeeper automatisch Verständisfrage

[weshalb]

Hallo, ich habe etckeeper mit git installiert, doch irgendwie werde ich aus der Funktionsweise nicht schlau. Wenn ich beispielsweise eine Konfiguration von Postfix mehrfach hintereinander ändere, hätte ich es gerne, dass mir diese Änderungen bei Bedarf nacheinander angezeigt werden, ohne nach jeder Änderung ein

Code: Alles auswählen

git commit -a

abzulassen. Auch würde ich gerne wissen, wo man bei Bedarf mit einem Schwung alle Konfigdateien aus etckeeper extrahiert, um sie auf ein anderes System zu übertragen. Geht so was mit etckeeper überhaupt?

[Meillo]

Hallo, ich habe etckeeper mit git installiert, doch irgendwie werde ich aus der Funktionsweise nicht schlau. Wenn ich beispielsweise eine Konfiguration von Postfix mehrfach hintereinander ändere, hätte ich es gerne, dass mir diese Änderungen bei Bedarf nacheinander angezeigt werden, ohne nach jeder Änderung ein

Code: Alles auswählen

git commit -a

abzulassen.

Mir ist nicht bekannt, dass das geht. Dazu braeuchte man ja schon so etwas wie inotify, um mitzubekommen, wann sich eine Datei aendert, aber auch dann kann man nicht unterscheiden, ob es sich um ein Zwischenspeichern oder um die fertige Version handelt.

Auch würde ich gerne wissen, wo man bei Bedarf mit einem Schwung alle Konfigdateien aus etckeeper extrahiert, um sie auf ein anderes System zu übertragen. Geht so was mit etckeeper überhaupt?

Vermutlich macht man das mit den ueblichen Mitteln des VCS, also in deinem Fall mit git. Etckeeper ist ja nur ein Frontend dazu, das automatisch per Hooks in APT committen kann.

[weshalb]

Danke

Nach näherer Betrachtung macht es für mich zumindest doch keinen Sinn, etckeeper einzusetzen. Gerade bei der Abarbeitung eines Themas auf meinem kleinen Server wäre das wie mit Kanonen auf Spatzen zu schießen. Wenn man beim Probieren jede Änderung erstmal commiten muss, hat man in meinen Augen mehr Arbeit.

Etckeeper ist wohl doch eher was für komplexere Konfigurationen und/oder, wenn mehrere Leute an einem Server arbeiten.

Für mich mach es mehr Sinn, händisch sämtliche Configfiles wegzusichern und gegebenfalls wieder einzuspielen.

[Meillo]

Nach näherer Betrachtung macht es für mich zumindest doch keinen Sinn, etckeeper einzusetzen. Gerade bei der Abarbeitung eines Themas auf meinem kleinen Server wäre das wie mit Kanonen auf Spatzen zu schießen. Wenn man beim Probieren jede Änderung erstmal commiten muss, hat man in meinen Augen mehr Arbeit.

Etckeeper ist wohl doch eher was für komplexere Konfigurationen und/oder, wenn mehrere Leute an einem Server arbeiten.

Für mich mach es mehr Sinn, händisch sämtliche Configfiles wegzusichern und gegebenfalls wieder einzuspielen.

Wenn du das Wegsichern weniger aufwaendig findest als das Committen, dann ja, sonst nicht. Ich vermute, dass du mit dem ``haendischen Wegsichern'' ein ``automatisches Wegsichern (d.h. per Cronjob)'' denkst, denn nur im dem Fall sparst du dir Arbeit ... dann kannst du aber auch per Cronjob automatisch committen lassen. Falls du aber wirklich von Hand `cp' aufrufen willst, dann kannst du ebenso von Hand `etckeeper commit' aufrufen.

Etckeeper bietet dir eine vollstaendig History, in der du suchen kannst, in der du herausfinden kannst, wann eine bestimmte Zeile geaendert wurde ... und du kannst zudem die Konfigurationsstand zu einem beliebigen Datum auschecken, was dann der weggesicherten Kopie entspricht.

Wenn du Versionskontrollsysteme verwenden kannst, dann sehe ich keinen ueberzeugenden Grund, weshalb das herkoemmliche Wegsichern besser sein koennte. Nur wenn dir Versionskontrollsysteme fremd sind (und du keinen Sinn siehst, sie zu lernen), dann kann ich verstehen, dass du lieber normale Dateikopien erzeugst.

(Ein richtiges Backup bietet Etckeeper uebrigens nicht, denn wenn du /etc loeschst, dann ist auch das Etckeeper-Repo weg. Fuer's Backup muss zu das Repo regelmaessig auf ein Backup-Medium klonen.)

[eggy]

Ich finds ganz praktisch bei Updates, kommt ja doch ab und an mal vor, dass ne neue Version irgendwas an der Config ändert. So muss ich nicht dran denken, und der Overhead ist nicht wirklich spürbar. Grade bei diesen super hilfreichen Auskünften von Kollegen/Kunden der Art "seit kurzem gehts nichts mehr, aber Weihnachten wars definitv noch ok" ist was git-artiges schon angenehmer als x Backups durchzusehn.

Du startest Deinen Dienst nach jeder Configänderung? Dann bau den commit doch einfach ins Startscript mit ein. Dann hast Du jede Version archiviert (incl dem Mist, aber die Guten kannst Du ja taggen, oder in unterschiedlichen Braches arbeiten, oder die überflüssigen Commits später zusammenführen http://de.gitready.com/advanced/2009/02 ... ebase.html ).

[ThorstenS]

Oder man definiert sich in der ~/.bashrc eine function, die man aufruft - ich liebe 1-Buchstaben aliase oder Funktionen, weil sie wirklich nicht zu viel Arbeit machen.

Es müßte ja nur ein cd /etc; git commit -a -m "automatischer commit" beinhalten. Wem das zu viel Arbeit ist, dem kann ich nicht helfen.
Über inotify mit einem "exec on write close" wären sogar diese zwei Tastenanschläge wegoptimiert.
Das schöne an etckeeper ist aber doch, dass ich commit-messages übergeben kann. Die helfen mir in 1-4 Monaten weiter. Nicht die puren Änderungen…

[heisenberg]

Meine /etc-Verzeichnisse werden täglich einmal per cron comitted. Das funktioniert auch, wenn ich das committen mal vergesse.

Das comitten geht auch einfacher mit:

Code: Alles auswählen

etckeeper commit -m "commit message"

[Meillo]

Das comitten geht auch einfacher mit:

Code: Alles auswählen

etckeeper commit -m "commit message"

Laut Manpage braucht es noch nicht mal das `-m'.

[weshalb]

Meine /etc-Verzeichnisse werden täglich einmal per cron comitted. Das funktioniert auch, wenn ich das committen mal vergesse.

Das comitten geht auch einfacher mit:

Code: Alles auswählen

etckeeper commit -m "commit message"

Ich wollte das dann doch nochmal aufleben lassen. In der etckeeper.conf ist bei mir zum automatischen Commiten

AVOID_DAILY_AUTOCOMMITS=1
AVOID_COMMIT_BEFORE_INSTALL=1

eingestellt. In der /etc/cron.daily/ befindet sich das etckeeper Script. Doch irgendwie wird es nicht automatisch aufgerufen.

cat /etc/crontab

# /etc/crontab: system-wide crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

run-parts --test /etc/cron.daily

/etc/cron.daily/apache2
/etc/cron.daily/apt
/etc/cron.daily/aptitude
/etc/cron.daily/bsdmainutils
/etc/cron.daily/dpkg
/etc/cron.daily/etckeeper
/etc/cron.daily/logrotate
/etc/cron.daily/man-db
/etc/cron.daily/mlocate
/etc/cron.daily/passwd
/etc/cron.daily/samba
/etc/cron.daily/spamassassin

Funktioniert das Script bei dir?

[ThorstenS]

Ich denke du hast die Übersetzung von AVOID noch nicht ganz verinnerlicht.

[rendegast]

rsnapshot
legt aktiviert (/etc/cron.d/rsnapshot) Kopien von
/home
/etc
/usr/local
(/etc/rsnapshot.conf)
in /var/cache/rsnapshot/localhost/ an.

Ich lasse es einfach mal mitlaufen nur für /etc.

[weshalb]

Ich denke du hast die Übersetzung von AVOID noch nicht ganz verinnerlicht.

Autsch.