I'd like to use etckeeper on Mac OS X, specifically 10.9.1 or above, primarily to get proper file-metadata control in git as per http://goo.gl/4opL4L . Not for /etc nor pkg-management integration.
I git-cloned the etckeeper source and tried to build on a homebew-based 10.9.1 macos system, with no success. Details below. Any suggestions? Is there any chance of the current code base or branch building and running successfully on macos? If not, can you scope the amount of effort to port it simply to support file-metadata management outside of /etc, and no pkg management?
-Johnny Utahh
ps. Here's the details:
mba4mme Feb 07 13:29:42 ~/.../etckeeper$ git remote show origin | grep URL
Fetch URL: http://git.joeyh.name/git/etckeeper.git
Push URL: http://git.joeyh.name/git/etckeeper.git
mba4mme Feb 07 13:29:50 ~/.../etckeeper$ git rev-parse HEAD
214332b020b03e603d84ab3327f1c17509b49c47
mba4mme Feb 07 13:29:52 ~/.../etckeeper$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
mba4mme Feb 07 13:30:02 ~/.../etckeeper$ make
sed -i~ "s/Version:.*/Version: $(perl -e '$_=<>;print m/\((.*?)\)/'<debian/changelog)/" etckeeper.spec
rm -f etckeeper.spec~
./etckeeper-bzr/__init__.py build || echo "** bzr support not built"
Traceback (most recent call last):
File "./etckeeper-bzr/__init__.py", line 6, in <module>
from bzrlib.errors import BzrError
ImportError: No module named bzrlib.errors
** bzr support not built
mba4mme Feb 07 13:30:07 ~/.../etckeeper$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.9.1
BuildVersion: 13B42
mba4mme Feb 07 13:30:09 ~/.../etckeeper$
mba4mme Feb 07 13:31:15 ~/.../etckeeper$ bzr --version | head -1
Bazaar (bzr) 2.6.0
mba4mme Feb 07 13:31:22 ~/.../etckeeper$
mba4mme Feb 07 13:31:47 ~/.../etckeeper$ which bzr
/usr/local/bin/bzr
mba4mme Feb 07 13:31:53 ~/.../etckeeper$ brew list bzr
/usr/local/Cellar/bazaar/2.6.0/bin/bzr
/usr/local/Cellar/bazaar/2.6.0/libexec/bzrlib/ (979 files)
/usr/local/Cellar/bazaar/2.6.0/libexec/bzr
/usr/local/Cellar/bazaar/2.6.0/share/man/man1/bzr.1
mba4mme Feb 07 13:31:58 ~/.../etckeeper$
thanks for etckeeper! it's really useful :)
I'm always find myself trying to do "etckeeper status" so I've put in /etc/etckeeper/status.d/50status
#!/bin/sh
if [ "$VCS" = git ]; then
[ -d .git ] && git status
fi
How about calling "sync; sync" at the end of "etckeeper commit"? /etc/.git (or whichever DVCS' repo) is worth ensuring to be immediately committed to the disk.
--- a/commit.d/50vcs-commit
+++ b/commit.d/50vcs-commit
@@ -87,3 +87,5 @@ elif [ "$VCS" = darcs ] && [ -d _darcs ]; then
darcs record --author="$USER" $DARCS_COMMIT_OPTIONS
fi
fi
+
+sync; sync
--Kai
I would love to see some notify support.
Would be cool to be able to run etckeeper as daemon that will automaticly commit on each file change, best with information on who actually made the change. Information about who made the change probably will require audit support or fanotify under Linux (not sure which provides all required info and is best suited for this task).
That would make etckeeper kind of backup PLUS logging solution. In this mode it would also work with any package management software, including plain old "cp".
--arekm
Hey,
what is the best way to kind of "temporary commit" changes in the working directory to be able to fast install some packages with APT? Git stash is not what I want, since I cannot change the working directory. (e.g. for server programs like postfix, which really poll for changes in /etc). Git rebase afterwards is also nothing I want to do in /etc. What is the best way? Is there a clever way? --sandoz (2011-06-08)
Hi Joey, 0.44 mentions OS X portability fixes, but metastore doesn't compile on OS X. Therefore, how is etckeeper run on OS X?
etckeeper has not used metastore for a long time. --Joey
Thanks for etckeeper; I just used it in anger for the first time. I don't know for a fact that it really made my life better, but it makes me feel better. The story: I applied the usual security upgrade to my desktop box, and after rebooting, noted with dismay that my monitor, which had previously been happily running at 1280x1024, was now running at 640x480. (Typical Linux story.) So I poked around, and dimly remembered that I could run 'dpkg-reconfigure xserver-xorg', which I did. (I realize that's probably not the best tool for what I was doing, but it's all I remembered). That worked -- the monitor is now back to its old 1280x1024 self. Naturally the xorg.conf file is totally different; both the current version and the old version are utterly incomprehensible to me ... but the point is I've got a record of all of them, plus a comment explaining what I did and why. That's why etckeeper makes me feel better. Thanks again.
Oops, it just saved my butt again. I swear I'll try not to append to this comment every time it proves useful ...
Hey, I was wondering if there's any intention to support subversion?
Subversion is not a really good fit for etckeeper, especially because of all the .svn directories. I do not plan to work on supporting it myself, if someone works up a reasonable patch I'd probably apply it. --Joey
What would you say is the best hosting site to use with etckeeper (git)? It should probably be private right?
etckeeper does not need a hosting site; it checks /etc into a git repository that is local to the machine.
If you want to push that repository elsewhere, I'd be sure to only push it to a machine that you control and trust. Gitweb is right out, in other words. --Joey
Also can you use etckeeper for backing up home directory dotfiles?
That's not its purpose, though you can find info elsewhere on my site about storing home in VCS. --Joey
I understand that it wasn't designed for storing home but, what would be the problem if we used it for that? Most likely I'm missing something but It seems possible with the current code. --George
The idea of managing config files from remote computers sounds interesting to me. Is it possible to pull and push updates through git without loss of original metadata? Thanks in advance, Chris.
etckeeper restores the metadata when
etckeeper initis run. --Joey
Hi.
After using for couple of months my own template system for maintaining and distributing config files I decided to seek for a better solution (my scripts have many limitations, I'd like rather to improve some other tool, then my SVN-basing scripts). etckeeper looks quite nice, I'm just wondering if it would be possible to use it for tracking other directories too - some scripts installed in /usr/local/bin, some configs of out-of-distro applications located in /opt or /srv etc. Actually, what about setting up a repository in / directory and configuring .gitignore to ignore all but some explicit specified dirs? Am I asking for trouble? Maybe it would make sense to create a repository by default in /, put into ignore file by default
*
!/etc
and then all ignores regarding /etc, thus leaving to the user the choice what else will be tracked?
TIA, Richard.
+1 --George
I'm running etckeeper; have happily not had need to use its results "in anger," (e.g. - haven't needed to use it to recover from a problem), but feel a fairly considerable weight alleviated from shoulders.
But a couple questions about backing up...
I'd quite like to pull the etckeeper material from all my hosts into possibly one(?) Git repository, so that the history would not only be on the respective hosts, but so that it would also be backed up elsewhere to assist with analysis and recovery.
What would be a reasonable approach to this?
My first thought is to set up a bare Git repo somewhere, and have each of my hosts push into a branch named after the host within that repo.
Thus... [backuphome]$ cd /gitkeeper; git init --bare
Then, on each host...
cd /etc ; git remote add -thostnamegitkeeper ssh://keepuser@keeperhost/gitkeeper ; git push gitkeeper
The fact that these are completely independent sets of configuration for each doesn't cause any problems, does it? I would not expect to be able to meaningfully merge anything between branches. Or perhaps cherry picking might work somewhat OK???
cbbrowne@acm.org
ummm, where are the docs please? thanks!
In the package. --Joey
Interaction bug with Ubuntu Software Centre (Ubuntu 10.10): all packages installed from the centre get failure message:
bzr: ERROR: Unable to determine your name.
Please, set your name with the 'whoami' command.
E.g. bzr whoami "Your Name <name@example.com>"
while bzr whoami from a terminal correctly reports "john doe johndoe@example.org", as does sudo bzr whoami. After the above etckeeper unclean is quiet, so presumably there is in fact no real error.
Please feel free to submit bug reports via the Debian BTS, not here. (Also, bug reports without version numbers are not very useful. --Joey
I just saw that etckeeper is now integrated to TurnKey-Linux, version 11.1. Great work Joey! -- PRouleau
On RH flavored Linux systems network configuration files are typically (if not controlled by NetworkManager) hardlinked in 2-3 places and thus cause warnings like this:
etckeeper warning: hardlinked files could cause problems with git:
sysconfig/network-scripts/ifcfg-eth0
sysconfig/networking/profiles/default/ifcfg-eth0
sysconfig/networking/profiles/default/hosts
sysconfig/networking/profiles/default/resolv.conf
sysconfig/networking/devices/ifcfg-eth0
hosts
resolv.conf
every time etckeeper is run, which is kind of annoying. What would you propose to do about this? --Thomas
+1 for RH problems (perhaps a AVOID_SPECIAL_FILE_WARNING option?). How serious the problem with hardlinks is anyway? Maybe at least these (NetworkManager) files should be somehow ignored?
Also, openvpn/openvpn-status.log should be ignored. It is rewritten every minute, no need to track it. prelink.cache should also be ignored I guess.
Added these additional FHS violators to the default ignores. --Joey
It'd be great if the automatic commits generated by the package manager could include the command run in the commit message, like
/etc$ sudo git log --oneline
6bc763e committing changes in /etc after apt run: apt-get install emacs23-nox
96f15bf committing changes in /etc after apt run: apt-get upgrade
...
I looked at the post-invoke hook that etckeeper puts in /etc/apt/apt.conf.d, but it wasn't clear to me if there was an easy way to get the apt-get command line that was run directly. But I thought maybe one could scrape that out of the logs, if apt-get writes the /var/log/apt/history.log entry before it calls the post-invoke hooks? I realize there might be a bit of a race condition there with multiple executions of apt-get, but it seems like it'd usually work pretty well. --Nick
There is some odd behavior when doing a rebase with a reword. The .etckeeper file gets conflicts (could be because of http://git.661346.n2.nabble.com/rebase-i-reword-runs-pre-commit-hook-with-curious-results-td7244648.html). This is easy to work-around with a manual etckeeper pre-commit before git rebase --continue but I wonder if the pre-commit hook can be modified to make this work seamlessly?
I would like to use awesome etckeeper not only for /etc, but also for tracking python code at /usr/lib/python2.7/dist-packages/. In my specific situation people sometimes log in to servers and change code there on the fly. Should I just add one line 'etckeeper commit -d /usr/lib/python2.7/dist-packages/ "daily autocommit" >/dev/null' in cron job here https://github.com/joeyh/etckeeper/blob/master/debian/cron.daily#L15 ? What else should I think about when using etckeeper for two dirs?