Version control on FreeBSD

B

balanga

Does anyone use any sort of version control for maintaining scripts or configuration files such as /etc/rc.conf or /etc/fstab etc.?

Any recommendations?
 
balanga said:
Does anyone use any sort of version control for maintaining scripts or configuration files such as /etc/rc.conf or /etc/fstab etc.?
Click to expand...
It depends on what you are trying to achieve.

If all you want is local historical changes, and reversions, rcs(1) is both venerable and fit for purpose. You really only to learn two commands, namely ci(1) and co(1).

If you want central management and automated provisioning, then you should investigate things like Puppet and Ansible. These are very widely used in large data centres.
 
For servers I keep the basic configuration (i.e. rc.conf, sysctl.conf, crontab, etc...) in git repositories. Same goes for things like templates and configs for bhyve-vm or iocell as well as dotfiles for my personal user accounts (desktop, laptop) and default ones I use on servers.

Those repositories can be easily integrated into ansible or puppet scripts for fully automated host (or jail) setups/rebuilds.
 
I don't check in /etc/rc.conf, but I have a general startup script that I call from /etc/rc.local and that is checked in. I use CVS for that.
 
For those of you using version control for config files, how do you track only the files that you care about? Three options I'm aware of:

  1. Nothing special - add the files you care about. git status will just list a bunch of stuff in "untracked" files.
  2. Ignore * and force add the files you care about.
  3. Make a repo with only the files you care about outside of /etc, and copy them into place as needed.
 
patmaddox said:
For those of you using version control for config files, how do you track only the files that you care about? Three options I'm aware of:

  1. Nothing special - add the files you care about. git status will just list a bunch of stuff in "untracked" files.
  2. Ignore * and force add the files you care about.
  3. Make a repo with only the files you care about outside of /etc, and copy them into place as needed.
Click to expand...

My CVS tree is checked out in a different place and there is an ./install.sh script (sometimes a Makefile).
 
I tend to use CVS, however Git's --git-dir (or GIT_DIR environment) is very handy. You can basically have config files on your system but then use things like git diff, without needing to add a toplevel .git directory to the root/. The data can be out of tree and separated from the VCS metadata.

I would probably recommend Git going forward.
 
Good topic, interesting options.
For me, I use local cvs to track changes to files like rc.conf and others. Mostly because I don't have lot of systems, I tend to install major upgrades (think 13.x to 14.x) on new devices. I have user home directories on separate devices from OS so I can do a fresh install and then apply local changes easily.
 
RCS does not use a central repository. It pre-dates that concept.

The default behaviour it to store the revision history for each file in another file in the same directory with ",v" appended to the file name.

In practice, almost everybody will create a directory called RCS (one in each directory where you have files under revision control), and if rcs(1) finds it, will store the revision history there:
Code: 
[strand.130] # cd /etc
[strand.131] # mkdir RCS
[strand.132] # ci hosts rc.conf
RCS/hosts,v  <--  hosts
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> initial version
>> .
initial revision: 1.1
done
RCS/rc.conf,v  <--  rc.conf
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> initial version
>> .
initial revision: 1.1
done
[strand.133] # ls -lad hosts rc.conf
ls: hosts: No such file or directory
ls: rc.conf: No such file or directory
[strand.134] # co -l hosts rc.conf
RCS/hosts,v  -->  hosts
revision 1.1 (locked)
done
RCS/rc.conf,v  -->  rc.conf
revision 1.1 (locked)
done
[strand.135] # ls -lad hosts rc.conf
-rw-r--r--  1 root  wheel  4994 Oct  4 08:57 hosts
-rw-r--r--  1 root  wheel   715 Oct  4 08:57 rc.conf
[strand.136] # ls -al RCS
total 18
drwxr-xr-x   2 root  wheel     4 Oct  4 08:57 .
drwxr-xr-x  34 root  wheel   126 Oct  4 08:57 ..
-r--r--r--   1 root  wheel  5197 Oct  4 08:57 hosts,v
-r--r--r--   1 root  wheel   918 Oct  4 08:57 rc.conf,v
 
If you really need Version Control, I find git easiest for this scenario. (Words I admittedly never expected to put together.)

git init . && git add * && git commit -m “initial commit” and you’re off.
 
gpw928 said:
RCS does not use a central repository. It pre-dates that concept.

The default behaviour it to store the revision history for each file in another file in the same directory with ",v" appended to the file name.
Click to expand...
Just to add to this, its actually my main reason I use CVS. If you are familiar with RCS, it is basically the format used internally for CVS repositories. This means that unlike some random Git, Subversion database blob, the CVS/RCS data is human readable. This gives me a little bit more reassurance if anything goes horribly wrong.
 
Eric A. Borisch said:
If you really need Version Control,
Click to expand...

After reading


where it says:

The true purposes of version control​


What you really want version control for is to get up the courage to rip apart code that's working already so that you can improve it, without being afraid that you're going to totally screw up and lose a version that sort of works. If you've ever worked without version control as a safety net, you know the kind of things you end up with. Any development directory ends up littered with manual backups like:

some_program.c.old
some_program.c.older
some_program.c.not_so_old
some_program.c.ok
some_program.c.sorta_ok
some_program.c.ng
some_program.c.ngier
some_program.c.almost_not_ng
some_program.c.getting_there
Click to expand...

I find myself in a similar situation, which I want to get away from.
 
some_program.c.old
some_program.c.older
some_program.c.not_so_old
some_program.c.ok
some_program.c.sorta_ok
some_program.c.ng
some_program.c.ngier
some_program.c.almost_not_ng
some_program.c.getting_there
Click to expand...
Just want to tell that as an non-coder just purely amateur, the given example is so me, it is just hilarious to read it 🤣

I use git to store things online and have them available when I tinker, but using git when writing a script is not a reflex that I have ... well on the other hand I suppose less than 40 lines shell scripts don't really need it.
 
gotnull said:
Just want to tell that as an non-coder just purely amateur, the given example is so me, it is just hilarious to read it
Click to expand...
Everybody does this at first. Right up until they find the benefits of using a version control system.

gotnull said:
well on the other hand I suppose less than 40 lines shell scripts don't really need it.
Click to expand...
I have a bunch of small scripts, don't have a separate repository for each, I just bundle all of them together in a single repo.
 
I also have a second mechanism, which is a central machine that pulls files like /etc/rc.conf and keeps them in a CVS tree for future reference.
 
I found a different solution: I run regular incremental file-level backup to a backup server, and for specific directories containing configuration files I run them every 10 minutes.
For the rare cases when one really wants to investigate what has been changed when, this is good enough. And it also gives protection against accidential deletion, like, you write stuff for an hour or so, and then somehow delete it unintentionally.
 
PMc said:
I found a different solution: I run regular incremental file-level backup to a backup server, and for specific directories containing configuration files I run them every 10 minutes.
For the rare cases when one really wants to investigate what has been changed when, this is good enough. And it also gives protection against accidential deletion, like, you write stuff for an hour or so, and then somehow delete it unintentionally.
Click to expand...

Exactly. If this is zfs-on-root, set up sysutils/zfstools automatic snapshots and call it good. Then even if you don't "commit" it, you still have history automatically getting captured.

This is what I've been trying to point out; if you don't need Version Control (and the associate ability to distribute versioned changes across multiple systems), this is a more foolproof approach, as there are no additional steps required by you to save versions as you change things -- it just happens.
 
Hello. I was searching about dotfiles on the forum and got here being kitte like the user case that I am looking for.
I maintain a .dotfiles at my ~/ user for things like X11, .config, etc.
It saves me a lot of time when I messs things ups and need to have a quick config of the daily things that I use.
Then it came to me an way to keep a good record of /etc configs of FreeBSD.
I keep then as templates and not symlinks as other things of my home user, but I allways have to keep in mind to update the templates separatly from the actual configs.
Would be a good way to have a root home dotfiles that creates symlinks of rc.conf, pf.conf and so on?
I use git to maintain, backup and track my dotfiles since I am not familiar with the others discussed here.
 
You must log in or register to reply here.
Back
Top