Config management

[beavers]

What do folks here do to manage and backup their config files? I previously had a system where I copied the default config file to ${config}.ORIGINAL in-place, then ran a script every so often to backup the edited file to a default location (~/configs). This had the benefit that I could easily see all modified configs on the system just by running `find / -name *.ORIGINAL`.

Lately, I've switched to just adding my own configs to /etc/changelist, then backing up the entirety of /var/backups.

I'd like to move to a simpler system that keeps _all_ historical changes, not just the most recent version. cvs or svn seem like overkill for this. Do folks out there have other kinds of config management systems that do this?

[jggimi]

Version control would be nice to have. I will admit that I made a first attempt with cvs(1) around 2006, but quickly discovered that the repository/working-directory schema with commit after revising to be less-than-useful to me. Other version control systems like devel/git also have commit phases.

Over the years, I've wondered if the rcs(1) tools without a cvs(1) repository would just be simpler and easier, but never had the time to investigate. I knew that one problem to overcome with rcs() is its "delete-on-check-in" function, making use of it in a production working directory problematic.

These days, I manage my small farm of servers and my workstation without version control.

---

Edited to add: I just discovered one can use the -l or -u option of ci(1) to eliminate the automatic deletion at rcs() check in. I think I may give rcs() a spin with a test server. I know that some planning will be needed to integrate sysmerge(8) operation on upgrades.

[jggimi]

I've played with rcs() for a little bit. My thoughts:

• It works. For /etc, you can use it to track changes to every file except spwb.db. There's no point to using it with random.seed.
• /etc/*/RCS directories can be used to keep the *,v files separated. It makes ls(1) directory listings a little less messy. There are more than 100 directories in /etc, so it is best to create these with find(1), with something similar to # find /etc -type d ! -name RCS -exec sh my.rcs.mkdir {} \; and a little one-line shell script.
• You will forget to use ci(1) with -l. Set this with a shell alias before you begin using rcs. On OpenBSD, strict locking is the default. You can change this after a new file's initial check in, but the alias is far easier than the extra (forgetful) step.
• The find() utility is your friend. Not just for RCS directories, but in order to track changes to all files in /etc.
• For a bulk initial check in of new files after install, upgrade, or pkg_add(1), use ci() with -t.
• After a sysmerge or other bulk upgrade, you can do mass check in of new files with ci() -i and -t, and then mass check in your changed files with ci() -j and -m.

No, I have not put this into production, I've only experimented briefly, and only in /etc.

[jmccue]

Originally Posted by jggimi

I've played with rcs() for a little bit.

I have used RCS for many years and still do for personal files, I find it very simple and easy to use. One nice thing, it is rather easy to move from RCS to CVS.

Been up almost 24 hours with issues and here comes rambling 'rant' to show how important using one is.

At work many years ago no one used a src ctl system, I put RCS on our devel system for our use and maintained it for my development. (no on wanted to use it).

Eventually, as you can guess, someone lost some code and the original developer was long gone. Finally I was able to convince Mang to make everyone use some 'src code ctl'. By then I found another group using CVS and asked if the group I was in could hook into it, so I moved the RCS files to CVS. Still no real support from Mang and it was a struggle to get a few people to use it, many complained But at least we had history and no lost files. Then Mang got interested in it when they wanted to find out when a change was made that caused an issue.

Since then religion set in and a Company wide git repository was created. Even getting approval to move to git was hard until the CVS people said they were shutting down CVS in favor of git.

Joys of a large company

[jggimi]

Originally Posted by jmccue

...it is rather easy to move from RCS to CVS.

I've been a CVS user for many years -- since I began using OpenBSD, in fact.

During experiments this week I discovered that OpenBSD's "OpenRCS" utilities do not support branching. As an example, the -b option is documented in the rcs(1) man page but not part of the case statement structure in the program, so it does not function. And the ci() utility will not permit branch creation except at the HEAD of the main trunk, which renders it broken. So if you want RCS branch support you'll need to either use cvs(1) or install devel/grcs and use grcs(1) and gci(1).

[ibara]

Patches welcome!

[ibara]

I also ended up making a portable version of OpenRCS for FreeBSD at the behest of some FreeBSD devs: https://github.com/ibara/OpenRCS

[jggimi]

Originally Posted by ibara

Patches welcome!

Yes. But I would first like to conduct the due diligence necessary to understand the history of OpenRCS development before submitting a diff to remove -b from the rcs(1) man page and from the syntax error output rcs() produces when you attempt to use -b.

Originally Posted by ibara

I also ended up making a portable version of OpenRCS for FreeBSD at the behest of some FreeBSD devs: https://github.com/ibara/OpenRCS

[ibara]

Originally Posted by jggimi

Yes. But I would first like to conduct the due diligence necessary to understand the history of OpenRCS development before submitting a diff to remove -b from the rcs(1) man page and from the syntax error output rcs() produces when you attempt to use -b.

Here I was hoping you were going to add branching support to OpenRCS

[jggimi]

We are still using GNU CVS, which handles branches in the same way as GNU RCS. I have not reviewed the many years of OpenCVS/OpenRCS development, but branch deltas are complicated. From Tichy's 1985 paper:

The naive solution would be to store complete copies for the tips of all branches. Clearly, this approach would cost too much space. Instead, RCS uses forward deltas for branches. Regenerating a revision on a side branch proceeds as follows. First, extract the latest revision on the trunk; secondly, apply reverse deltas until the fork revision for the branch is obtained; thirdly, apply forward deltas until the desired branch revision is reached.

[ibara]

Hooray! We've found a new OpenCVS and OpenRCS maintainer! All hail this new era of OpenCVS!

[jggimi]

Hah.








Hah.






No.

[hermano]

I also use RCS for /etc. It is simple and it works. Nuff sed.