[Discuss] Moving Your Everyday System to New Hardware
grg
grg-webvisible+blu at ai.mit.edu
Tue Sep 3 08:38:19 EDT 2024
On Tue, Sep 03, 2024 at 05:22:11AM -0400, Bill Bogstad wrote:
> It handles things like file permissions pretty well. One downside is
> that as far as I know it only handles files in /etc.
> It would be nice to use it more generically to manage configuration
> files on other directories.
looks like you can define ETCKEEPER_DIR to be whatever directory you want:
https://git.joeyh.name/index.cgi/etckeeper.git/tree/etckeeper#n106
(and you might also have to define a companion ETCKEEPER_CONF_DIR for each
ETCKEEPER_DIR if you're running it multiple times with multiple different
ETCKEEPER_DIRs? dunno whether or not it'll handle a shared conf dir well.)
On Tue, Sep 03, 2024 at 07:08:25AM -0400, Dan Ritter wrote:
> etckeeper is a wrapper around git that hooks into the
> packaging system to auto-commit when the packaging system makes
> changes, but if you want that functionality without the
> packaging system hooks, that's git with a local secondary repo.
etckeeper additionally handles file permissions (as bill mentioned), owners,
and more. in their words (https://etckeeper.branchable.com/README/):
Version Control Systems are designed as a way to manage source code, not as
a way to manage arbitrary directories like /etc. This means there are a few
limitations that etckeeper has to work around. These include file metadata
storage, empty directories, and special files.
Most VCS, including git, mercurial and bazaar have only limited tracking of
file metadata, being able to track the executable bit, but not other
permissions or owner info. (darcs doesn't even track executable bits.) So
file metadata is stored separately. Among other chores, etckeeper init sets
up a pre-commit hook that stores metadata about file owners and permissions
into a /etc/.etckeeper file. This metadata is stored in version control
along with everything else, and can be applied if the repo should need to
be checked back out.
git and mercurial cannot track empty directories, but they can be
significant sometimes in /etc. So the pre-commit hook also stores
information that can be used to recreate the empty directories in the
/etc/.etckeeper file.
and it also encourages you to use git directly on the repo it creates.
maybe think of it as a nice lightweight extension to git to let it track a
filesystem rather than just file contents.
--grg
More information about the Discuss
mailing list