Version Control for Configuration Files

Y

yth

It seems like an obvious way to do this is just to set up a git repo at the base of /etc directory.

But, I am not sure if I just had a great idea or a terrible one with implications that I just hadn't figured yet.

Is there any reason why this might a bad idea?

What is the standard practice?
 
Accidentally running git-clean that deletes untracked files in /etc is a good reason not to do it.

I'd keep everything you want to track in ~/etc-files/ and just have a command to install from ~/etc-files to /etc. Also, symlinking ~/etc-files to /etc might not be a bad idea.
 
I use rcs which used to always come with FreeBSD base, but no longer in 12.0+ (though now available in ports).
 
I've seen a few people using git for config files but I don't know I'd be so calm about keeping them on Microsoft's github public web site.
 
For some years now, I keep a number of configuration files on all of my machines in the directory /etc/config under CVS control. This directory has a Makefile for installing (symlinking) those files into their respective target locations as well as uninstalling (copying default file version from /usr/src or deleting the symlink). The configuration files I am keeping there include: csh.cshrc, csh.login, csh.logout, profile, printcap, mergemaster.rc, kernel configs, Xresources and some others.
 
drhowarddrfine said:
I've seen a few people using git for config files but I don't know I'd be so calm about keeping them on Microsoft's github public web site.
Click to expand...
You don't have to upload your git repositories to github. You can keep them locally, copy them to other machines, share them among friends or colleagues, all without making the publicly visible. I also don't understand the paranoia about Microsoft for public git repositories: Once you upload your stuff to a place where it is public (visible to anyone), what nasty stuff can Microsoft do which random other parties can't?
 
To summarize the discussion so far on points that no one has disagreed, it seems it's okay to use version control software with configuration files in /etc. To prevent some VCS command from damaging the configuration files, it might be a good idea to collect the files that have version controlled applied and place them elsewhere. In effect, the repo should not be the entire /etc directory. Ideally, we should use VCS that comes with FreeBSD base instead of ports because they are guaranteed to be around if something catastrophic happens. Presumably, this is because that program will be part of the live CD.

It seems most of the files in /etc is owned by root. I haven't exhaustively checked, but the overall consensus seems clear. Regular users will not be able to change them. If the repo is created by a regular user, would it mean VCS commands issued by the regular user will not be able to affect the file themselves only the history of the files? Assuming, root gives read access to all files to this user. Would this make it safer creating a repo with /etc?

It seems like people create a repo for some subset of configuration files in /etc. Is there a reason for this? Shouldn't every file be version controlled?
 
yth said:
It seems like people create a repo for some subset of configuration files in /etc. Is there a reason for this? Shouldn't every file be version controlled?
Click to expand...
I'd say that depends upon what your primary goals are when putting certain configuration files under version control. Do you just want to be able to track and if needed undo changes? Do you want to keep files in sync across multiple machines? For me the primary motivation was the latter, so the subset of files includes mostly those that will be the same across multiple machines. Other files like kernel configs I just like to keep in a central, version controlled place, which makes it easy to compare different configs and also saves you the headache should you accidentally delete your kernel config (i.E. by checking out a fresh /usr/src, reinstalling the system, etc). Some if not most of the files under /etc you will probably never have to touch at all, and they are already sort of version controlled by means of mergemaster(8) or similar update/upgrade mechanisms. Therefore I believe it is best to only put those files under version control you know you're going to change from the default.
 
I like the progress we're making in this thread. My current solution is using tar, which is far less than ideal.
Bash: 
mkdir /root/configs_backups/bacula_with_tls
mkdir /root/configs_backups/bacula_no_tls
# back up working configs
tar cf - /usr/local/etc/bacula/bacula-* | tar vxf - -C /root/configs_backups/bacula_no_tls/
# ${break_stuff}
# save broken configs
tar cf - /usr/local/etc/bacula/bacula-* | tar vxf - -C /root/configs_backups/bacula_with_tls/
# revert to working state
cd /root/configs_backups/bacula_no_tls
tar cf - usr/ | tar vxf - -C /
bacula restart
# compare broken and working configs
cd /root/configs_backups/bacula_with_tls
vimdiff /usr/local/etc/bacula/bacula-dir.conf usr/local/etc/bacula/bacula-dir.conf

I then diffget and diffput a smaller set of changes, reload or restart bacula and see what progress I can make.

Aside: Anyone that's used Bacula knows what a pain debugging new changes can be.
/usr/local/sbin/bacula-dir -fm -dt 999 -c usr/local/etc/bacula/bacula-dir.conf
 
Use ZFS (obviously with a ZFS root filesystem) and sysutils/zfstools for automatic snapshots.

Use (shameless plug to free software) my zfs_versions script (perhaps with --idiff) to see differences over time.

I've been doing this for years; it happens automatically (so you can't forget to commit a change) and is unobtrusive.

[edit: clarity]
 
yth said:
It seems like people create a repo for some subset of configuration files in /etc. Is there a reason for this? Shouldn't every file be version controlled?
Click to expand...

I only revision control files I've changed which is far fewer than exist in /etc.

I should also mention I keep a week's worth of nightly cronjob rootfs mksnap_ffs(8) file system snapshots.
 
ralphbsz said:
You don't have to upload your git repositories to github.
Click to expand...
That's my point.
ralphbsz said:
I also don't understand the paranoia about Microsoft for public git repositories
Click to expand...
Skype.

Other things Microsoft touches and destroys.

I do not trust Microsoft. Even ignoring their vulgarities of the 1990s, I had technical issues with them when I first started mine. I also have a relative who leads a Microsoft shop and a former co-worker who was a project manager there. They feed me stories which grounds me into why I should never trust Microsoft.
ralphbsz said:
Once you upload your stuff to a place where it is public (visible to anyone), what nasty stuff can Microsoft do which random other parties can't?
Click to expand...
Uploading your stuff to a public site is another attack surface by others and something someone else can screw up, which also is my point.
 
Right. But everything on github's public part is public. Zillions of people have copies of it. Microsoft can not "steal" the intellectual property in it: it has been publicly posted! It is exactly as easy and as difficult to steal as if you had posted it to say kernel.org. It's like saying: "I left a bushel of apples out by the curb, with a sign "free" on it, and Microsoft came and took one, which proves that they are evil."
Microsoft could make it vanish, either out of malice or out of incompetence (lose the data, or delete it deliberately). But that has no long-term effect, since zillions of people have copies of the git archive, and it can easily be restored. There is a tiny window during which the uploaded git repository is vulnerable, namely right after the author uploads it, and before anyone has downloaded it, if and only if the author immediately deleted their copy. That's not realistic.

There is actually another vulnerability: Microsoft could clandestinely modify the code in the repository. If they do it through git, then a change record will be left in the git log. But they could go around and clandestinely modify the source directly. In a nutshell, they could introduce a bug. Again, zillions of people have copies of the same archive, so if this happens, a search (by comparing copies of files) would quickly find it. Microsoft could this thing exactly once, and then the whole world would hate them, so I don't think they will.

Look, once people post their code in public (whether on Microsoft's github or anywhere else), the "attack surface" becomes infinitely large against inspection, and vanishingly small against disruption. Now one could conclude what from you said above that you should never disclose your code to the public. Not a bad conclusion, but not for everyone.

Obviously, none of that applies to private (non-public) use of github. There you have to trust Microsoft. Which I personally don't very much either, just like you. But then, I don't upload my valuable source code to github, never have ... before they were owned by Microsoft, they were not particularly trustworthy either.
 
Agree and that's really my main point. That I don't understand why people would post configuration files to a public site. Or any such information that one isn't publishing just like a blog. The Microsoft dig comes about because I wonder whether, one day, you'll get a notice that github is free till October when it will be only $9.99 a month.
 
By virtue of the fact that git is distributed, I'd say go for it. You can maintain multiple copies of your repository, both remotely (github, gitlab, etc) and locally, maximizing availability and accessibility of your configuration files to all authorized clients. Both github and gitlab offer private repositories for free, which is a nice option in case your configuration files contain sensitive information you would like to obfuscate. It also goes without saying that you can distribute your local copy using encryption (with your own keys), rendering potentially malicious entities unable to read the content.
 
There's also BitBucket which works the opposite way of GitHub: by default all repos are private unless you pay to make them public.
I use it for my private code, mostly because I trust them slightly more than I trust Microsoft.
 
malavon said:
There's also BitBucket which works the opposite way of GitHub: by default all repos are private unless you pay to make them public.
Click to expand...
It's the same with a phabricator instance on Phacility. I've used their free signup to test things. The free instance you can get with Phacility allows to create an unspecified number of repositories, git, subversion or mercurial, and they're all 'private' by default. The only limitation I found was max. 5 user limit. But I liked it so much I set up my own server with devel/phabricator.

But this is probably a bit overkill just to store some configuration files. But I already have it running for a bunch of other pet projects.

(Phabricator is also used by FreeBSD; https://reviews.freebsd.org/)
 
SirDice said:
The only limitation I found was max. 5 user limit.
Click to expand...
I just tried out of curiosity and it says that "Test instances are temporary! All data on test instances is automatically destroyed after 7 days.". Did I miss something ?
 
Hmm.. Looks like they changed it. I rechecked my own free instance and it's still there, including a bunch of test repositories I created. Last time I used it was more than a year ago.

The free instances probably got abused for all sorts of bad things :(
 
You must log in or register to reply here.
Back
Top