Using etckeeper - protection and other questions

Following the suggestion made Putting /etc under source control I have installed ETCKEEPER.

It seems pretty good but I have some questions.

• Is the any way off putting the command you do into the change message. So if I run apt-get install widget I would like the first line of the commit message to be something like install widget rather than a less helpful committing changes in /etc after apt run

• I want to be able to do enquiries on the bzr repository from an ordinary user. But I am prevented by the protection on .bzr directory. Are there any gotchas in changeing this to a+r

  drwx------ 6 root root 4096 Aug 30 13:00 .bzr

• Are there any gotchas in removing files (such as /etc/shadow/ from etckeeper control

If you look at the full bzr log rather than the shortlog, you'll see that committing changes in /etc after apt run is followed by a list of the packages that changed. At least, that's the behavior on my Ubuntu laptop and server. For the vast majority of cases, I suspect that's more useful than a "sudo apt-get upgrade" commit message.

The reason you're prevented from accessing the bzr log as an ordinary user is that the bzr repo has full access to the shadow repository. Probably the biggest gotcha to stopping this is that if you remove a file from the bzr repo, it will still be available in older revisions. There's probably some voodoo you can use along the lines of svndumpfilter | svnadmin --import but for bzr, but I haven't tried it.

One alternative you might try is sudo su. Or perhaps you can make a new user and group, put the user in that group, give the group access to .bzr, and su to that user for operations of bzr interest.

Is the any way off putting the command you do into the change message.

Understanding how etckeeper works means you have to understand how version control systems work. With VCS systems you have the concept of your repository, basically a database of all the changes, the working directory where you are currently changing things.

Etckeeper can actually use one of several DVCS back-ends, it can support bzr, git and hg. Whatever back-end you use it all works about the same. I use git as the back-end since I am far more familiar with git.

With Etckeeper, your working directory is almost always /etc, though you can use it for other directories. When everything about the current state of your working directory has been commited your working directory is considered to be clean. If you make a change to some file and would like your change to be committed to the repository you run the command etckeeper commit "Your log message here". You can check to see if you repository is in a clean state by running a command like etckeeper unclean && echo $.

With the background out of the way I can go into how etckeeper hooks into to help you keep track of what apt does. When etckeeper is installed a config file is added to the apt configuration at /etc/apt/apt.conf.d/05etckeeper. This sets up some hooks so when apt is asked to install a package(s) it will run command before the installation is started, and it will run a command after the install is complete. To see exactly what the pre and post install command do take a look at the scripts in the /etc/etckeeper/pre-install.d and /etc/etckeeper/post-install.d directories.

Basically the pre-install command will do a commit if your working directory is not clean. If you don't like this, you could simply remember to manually run a commit after you change anything. If you strongly object to the auto-commit you can adjust your /etc/etckeeper/etckeeper.conf file and uncomment the AVOID_COMMIT_BEFORE_INSTALL=1 line. Making this change will mean that you will be forced to manually commit before you can run apt. If you really don't like the auto-commit you may also want to disable the daily auto-commit, present in newer versions.

I want to be able to do enquiries on the bzr repository from an ordinary user.

That is a extremely bad idea in my opinion. There are many files in /etc that should not be readable to a end-user. If you want to make your life easier you could setup sudo to not prompt your account for a password when you use bzr or etckeeper.

Are there any gotchas in removing files (such as /etc/shadow/ from etckeeper control

The right way to do this is to use the ignore feature for the DVCS backend you have chosen. If you where using git you would add the file to your /etc/.gitignore, I believe there is a /etc/.bzrignore that should do the same thing, but you may need to bzr expert to confirm that for you. Personally, I think I like to track the /etc/shadow file since it allows me to know if someone evil has managed to modify a service account which is supposed to have a disabled password, to have a password which would allow it to be used for logins.