Discussion:
Config-/Dotfiles in CVS
(too old to reply)
Michael Hekeler
2017-12-29 09:44:44 UTC
Permalink
Hello all,

in the past I used RCS on all machines for keeping configfiles in /home
or /etc or whatever.
Nearly everytime when I move to another machine I think that it would
be cool to have all of these repoistories centralized on a server.
So I thought I should convert all of these RCS to CVS.

Most of my non-production machines are on *BSD, Debian or other OS and
when I want to install CVS everyone is screaming: "Don´t use it..."

When I ask on internet for ideas how to keep configfiles under revision
control also everyone screams: "don´t use CVS..." and instead of
talking about concepts (symlinks, woring dir,...) most people give
ready-made solutions with git or whatever is their preferred
software.

I can´t understand why I "shouldn´t use cvs". Because it is old?
Hmmm... Latex is old, vi is old, rcs is old... all of them are useful
and I love to use them

Although I know that my question is not 100% OpenBSD related, I would
ask here for concepts/ideas how to keep configfiles under revision
control, because I know that there are many experienced admins on this
list.
Ingo Schwarze
2017-12-29 11:31:12 UTC
Permalink
Hi Micheal,

it all depends on your specific needs and the scale of your deployment.

When people maintain very large numbers of machines and very often
commission new ones and decommission old ones, i often hear such
people say that they wouldn't be able to handle their workload
without tools like ansible or puppet, but i don't have experience
with such tools.

I still use RCS for a number of config files on a number of machines
where backup is taken care of in some different way.

I don't have the slightest doubt that there may be situations where
CVS achieves the best balance of simplicity and features provided.
Even if you would give more details about your deployments, nobody
could judge better than you yourself whether that is the case for
your specific purposes.

CVS is not very actively maintained, neither by the crowd at
nongnu.org nor by OpenBSD, but that shouldn't be much of a problem
for the purpose at hand. It poorly handles branches, renames, and
reverts of change sets touching many files, but probably neither
is relevant for your purpose. In principle, i don't see anything
wrong with using it, if it fits your task.

Yours,
Ingo
john slee
2017-12-29 11:55:23 UTC
Permalink
I've not gone beyond a few thousand servers with Puppet but I can share a
few things.

* initially it feels like a *whole lot* of busy-work to get to a
minimally-useful level

* once there, knowing you can rapidly replace things is good for your
stress levels!

* in my experience the community Puppet modules are almost universally
garbage
(even when used on the Linux systems they are typically designed for)

* don't split your Puppet code up into lots of separate repositories, it
becomes too
difficult to do very basic things like "check all production environments
for X" (been
there/done that, it was an unmitigated disaster)

* some kind of monitoring of "how recently did Puppet succesfully apply a
manifest?"
is important to prevent config drift

* listen to the linter!

Other than the Puppet community module "quality", the same probably applies
to
any config management tooling; I'm just talking about Puppet because I've
used it.

I would consider it (much) more important to understand the tools you are
using
than to change tooling to be fashionable.

Also here's some notes I took last year on running Ruby things on OpenBSD:

http://jslee.io/post/151188252217/rubygems-and-openbsd

Pupistry as mentioned in that post is great if you want to use Puppet but
don't
want to run a Puppet master server

John
Post by Ingo Schwarze
Hi Micheal,
it all depends on your specific needs and the scale of your deployment.
When people maintain very large numbers of machines and very often
commission new ones and decommission old ones, i often hear such
people say that they wouldn't be able to handle their workload
without tools like ansible or puppet, but i don't have experience
with such tools.
I still use RCS for a number of config files on a number of machines
where backup is taken care of in some different way.
I don't have the slightest doubt that there may be situations where
CVS achieves the best balance of simplicity and features provided.
Even if you would give more details about your deployments, nobody
could judge better than you yourself whether that is the case for
your specific purposes.
CVS is not very actively maintained, neither by the crowd at
nongnu.org nor by OpenBSD, but that shouldn't be much of a problem
for the purpose at hand. It poorly handles branches, renames, and
reverts of change sets touching many files, but probably neither
is relevant for your purpose. In principle, i don't see anything
wrong with using it, if it fits your task.
Yours,
Ingo
Michael Hekeler
2017-12-29 17:00:32 UTC
Permalink
Am Fri, 29 Dec 2017 12:31:12 +0100
Post by Ingo Schwarze
Hi Micheal,
it all depends on your specific needs and the scale of your
deployment.
of course ;-)
Post by Ingo Schwarze
When people maintain very large numbers of machines and very often
(...)
Even if you would give more details about your deployments, nobody
could judge better than you yourself whether that is the case for
your specific purposes.
I want to keep track of my changings in configfiles
like "/etc/ssh/sshd_config" or "~/.tmux.conf" and so

Normally I create "/root/RCS" and "~/RCS".
Then in every directory with configfiles that I want to change I
create a symlink ./RCS -> /root/RCS (in the example of sshd_config I
will create /etc/ssh/RCS as symlink to /root/RCS. So when I check in
sshd_config the revision file goes to /root/RCS
When I setup a new machine I can look in the older host's /root/RCS and
it shows me which files I have to edit (or better: which files I edited
on that host).

I am sure that every admin has its own way to do that. But I know
that it is always a good idea to listen carefully to more experienced
people.
That´s why I am asking.
Nick Holland
2017-12-30 03:56:59 UTC
Permalink
On 12/29/17 12:00, Michael Hekeler wrote:
...
Post by Michael Hekeler
I want to keep track of my changings in configfiles
like "/etc/ssh/sshd_config" or "~/.tmux.conf" and so
Normally I create "/root/RCS" and "~/RCS".
Then in every directory with configfiles that I want to change I
create a symlink ./RCS -> /root/RCS (in the example of sshd_config I
will create /etc/ssh/RCS as symlink to /root/RCS. So when I check in
sshd_config the revision file goes to /root/RCS
When I setup a new machine I can look in the older host's /root/RCS and
it shows me which files I have to edit (or better: which files I edited
on that host).
I am sure that every admin has its own way to do that. But I know
that it is always a good idea to listen carefully to more experienced
people.
That´s why I am asking.
One thing I have done for years, since hard disks became too stupidly
big to even dream of using all of in many cases, is carve out a
partition that I store dated tar files of the /etc/ directory in.

So -- /bu/etc20171220.tgz /bu/etc20171221.tgz,
and so on. With compression, you can get YEARS of backup files in a 40g
partition.

No check in/check out. Diffing is non-trivial, but ... how often do you
do it? If you knew it worked yesterday(/last week) and is broke today,
restore yesterday(/last week)'s files and figure out why it broke after
you are back up and running.

For files like DNS zone files and pf.conf files, I wrote a script that
you run on either machine, it shows you the diff to the other machine,
has you comment/explain your change, then pushes your change over to the
other file. Works great for things where you have two different
machines that should normally be running the same data, but you need to
change and test that data from time to time. Done properly, you get
everything good from "change control" and revision control, and almost
zero effort on the part of the administrators. (yes, in the case of
DNS, it means you handle the replication manually rather than through
zone transfers -- and handling it manually is much better than the
idiotic DNS master/slave concept. Win all around).

Nick.
Michael Hekeler
2017-12-30 18:46:40 UTC
Permalink
Am Fri, 29 Dec 2017 22:56:59 -0500
Post by Nick Holland
...
Post by Michael Hekeler
I want to keep track of my changings in configfiles
like "/etc/ssh/sshd_config" or "~/.tmux.conf" and so
Normally I create "/root/RCS" and "~/RCS".
Then in every directory with configfiles that I want to change I
create a symlink ./RCS -> /root/RCS (in the example of sshd_config I
will create /etc/ssh/RCS as symlink to /root/RCS. So when I check in
sshd_config the revision file goes to /root/RCS
When I setup a new machine I can look in the older host's /root/RCS
and it shows me which files I have to edit (or better: which files
I edited on that host).
I am sure that every admin has its own way to do that. But I know
that it is always a good idea to listen carefully to more
experienced people.
That´s why I am asking.
One thing I have done for years, since hard disks became too stupidly
big to even dream of using all of in many cases, is carve out a
partition that I store dated tar files of the /etc/ directory in.
So -- /bu/etc20171220.tgz /bu/etc20171221.tgz,
and so on. With compression, you can get YEARS of backup files in a
40g partition.
No check in/check out. Diffing is non-trivial, but ... how often do
you do it? If you knew it worked yesterday(/last week) and is broke
today, restore yesterday(/last week)'s files and figure out why it
broke after you are back up and running.
For files like DNS zone files and pf.conf files, I wrote a script that
you run on either machine, it shows you the diff to the other machine,
has you comment/explain your change, then pushes your change over to
the other file. Works great for things where you have two different
machines that should normally be running the same data, but you need
to change and test that data from time to time. Done properly, you
get everything good from "change control" and revision control, and
almost zero effort on the part of the administrators. (yes, in the
case of DNS, it means you handle the replication manually rather than
through zone transfers -- and handling it manually is much better
than the idiotic DNS master/slave concept. Win all around).
Nick.
Interesting :-)
- thank you.
--
Viele Grüße
Michael
Robert Peichaer
2017-12-29 11:50:26 UTC
Permalink
Post by Michael Hekeler
Hello all,
in the past I used RCS on all machines for keeping configfiles in /home
or /etc or whatever.
Nearly everytime when I move to another machine I think that it would
be cool to have all of these repoistories centralized on a server.
So I thought I should convert all of these RCS to CVS.
Most of my non-production machines are on *BSD, Debian or other OS and
when I want to install CVS everyone is screaming: "Don??t use it..."
When I ask on internet for ideas how to keep configfiles under revision
control also everyone screams: "don??t use CVS..." and instead of
talking about concepts (symlinks, woring dir,...) most people give
ready-made solutions with git or whatever is their preferred
software.
I can??t understand why I "shouldn??t use cvs". Because it is old?
Hmmm... Latex is old, vi is old, rcs is old... all of them are useful
and I love to use them
Although I know that my question is not 100% OpenBSD related, I would
ask here for concepts/ideas how to keep configfiles under revision
control, because I know that there are many experienced admins on this
list.
I guess the devel/src package is what you are looking for.

http://www.catb.org/~esr/src/

Simple Revision Control is RCS/SCCS reloaded with a modern UI,
designed to manage single-file solo projects kept more than one to
a directory. Use it for FAQs, ~/bin directories, config files, and
the like. Features integer sequential revision numbers, a command
set that will seem familiar to Subversion/Git/hg users, and no
binary blobs anywhere.
Mike Burns
2017-12-29 16:20:11 UTC
Permalink
Post by Michael Hekeler
Although I know that my question is not 100% OpenBSD related, I would
ask here for concepts/ideas how to keep configfiles under revision
control, because I know that there are many experienced admins on this
list.
Consider sysutls/rcm -- it is an rc file manager that is agnostic to
version control.

(Which I maintain.)
Christian Groessler
2017-12-29 16:24:11 UTC
Permalink
Post by Mike Burns
Post by Michael Hekeler
Although I know that my question is not 100% OpenBSD related, I would
ask here for concepts/ideas how to keep configfiles under revision
control, because I know that there are many experienced admins on this
list.
Consider sysutls/rcm -- it is an rc file manager that is agnostic to
version control.
(Which I maintain.)
I'm using RCS for that ("ci", "co", "rlog", "rcsdiff").

regards,
chris
Michael Hekeler
2017-12-29 17:38:17 UTC
Permalink
Post by Mike Burns
Consider sysutls/rcm -- it is an rc file manager that is agnostic to
version control.
Looks interesting.
But can rcm handle files in other directories than in $HOME?
for example:
* sshd_config in /etc/ssh
* my.cnf in /etc
* foo.conf in /etc/foo
Mike Burns
2017-12-29 18:34:12 UTC
Permalink
Post by Michael Hekeler
Post by Mike Burns
Consider sysutls/rcm -- it is an rc file manager that is agnostic to
version control.
Looks interesting.
But can rcm handle files in other directories than in $HOME?
* sshd_config in /etc/ssh
* my.cnf in /etc
* foo.conf in /etc/foo
It cannot, no. That might be better handled by e.g. chef, ansible,
puppet, etc.
Loading...