26

I am thinking on a system, where /etc were tracked on a remote git repository. I am thinking on a git workflow, where every host machine where a different branch.

Every previous versions on every machine could be easily tracked, compared, merged.

If a /etc modification had to be committed on many machines, it could be easily done by some merging script.

In case of an "unwanted" /etc change, this could be good visible (even alarm scripts could be tuned to watch that).

Anybody used already a such configuration? Are there any security problems with it?

Improve this question
2
  • 8
    There is etckeeper which is already used on many systems. It does not offer all features you asked for. E.g. it has one repository per host, not a central one. Commented Jun 23, 2014 at 8:39
  • What files are you interested in or what files have been changed unwanted in the past? I ask because I think Git is not the right way to solve problems caused at another point in your workflow. Further: if someone forgets to commit multiple changes Git is worthless. Could you please explain your environment? Do you have test and QA envrionments identical to production? Do you have much more than two or three hosts of the same type/purpose or is it heterogenous? What is more important: compare hosts configurations or track one hosts config over time? Commented Jun 25, 2014 at 19:54

2 Answers 2

Reset to default
13

The program etckeeper does manage /etc in git, you just need to change the default vcs backend from bzr to git in /etc/etckeeper/etckeeper.conf.

It is installed by default in Ubuntu Linux, and handles the common cases of when to commit automatically.
It commits before installing packages in case there are uncomitted manual changes, and after installing.

Improve this answer
0
12

The problem with tracking configuration for /etc in git is that all you really gain by doing so is version control (most git novices don't even know how to tag and branch properly, so unlikely at that point) and the ability to rollback (again, if you aren't tagging properly, you don't gain anything but a log to blame people); but you lose templating (cant template because git doesn't provide that), and scaling out (you cant apply the configuration anywhere else; especially if you are using distributed databases like Elasticsearch), and automated systems management (again, git doesnt provide this).

With that being said, what you are probably looking for is configuration management; that ties in templating, git, and basic scripting to manage configuration. This, of course is going down the direction of DevOps and Infrastructure as Code.

To add to this; Ansible has ansible-pull which can pull the latest repo of your playbooks from git; the same is also true for Chef. Basically, modern Linux administrators shouldn't be using something like etckeeper. Chef also has client-server mode where you can manage all systems with the chef-client based on environment, roles, and cookbook versions; things you cannot do with git solely and at scale.

Improve this answer
1
  • 1
    Not only the rollback get I with git. I get also comparability (both between machines and between time), and also synchronization. But I think the idea about some more targeted tools is useful. Commented Jul 26, 2017 at 21:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.