Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
Say I had to change the permissions of some file in /etc/ssl to allow a program to read a private key file:
$ cd /etc
$ chgrp ssl-cert ssl/private/key.pem
$ chmod g+r ssl/private/key.pem
$ git status
On branch master
nothing to commit, working directory clean
How do I tell etckeeper that some file permissions have changed in order to commit them? I know that the permissions are kept in /etc/.etckeeper, but couldn't find any way to update that file.
git itself does not provide ownership and privileges information, besides executable bit information. The solution for you is to use etckeeper data.
Looking into the documentation, we have:
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.
So, the ownership of your directories are kept in /etc/.etckeeper, which is monitored by git as well. ;)
etckeeper commit should solve your problem.Depending on your scale, I would think about more complex and useful configuration management tools like Salt, Ansible, Puppet, Chef and so on.
etckeeper commit.etckeeper commitit might tell me that there isnothing to commit, but thenetckeeper vcs statustells me that now the metadata file.etckeeperhas been modified, so a subsequent run ofetckeeper commitactually does find something in need of committing. Whenever I need to regenerate the metadata file, I prefer to runetckeeper pre-commitbecause it is less confusing.