Discussion:
Config-/Dotfiles in CVS
(too old to reply)
Michael Hekeler
2017-12-29 09:44:44 UTC
Permalink
Raw Message
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
Raw Message
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
Raw Message
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

On 29 December 2017 at 22:31, Ingo Schwarze <***@usta.de> wrote:

> 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
Raw Message
Am Fri, 29 Dec 2017 12:31:12 +0100
schrieb Ingo Schwarze <***@usta.de>:

> Hi Micheal,
>
> it all depends on your specific needs and the scale of your
> deployment.

of course ;-)

> 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
Raw Message
On 12/29/17 12:00, Michael Hekeler wrote:
...
> 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
Raw Message
Am Fri, 29 Dec 2017 22:56:59 -0500
schrieb Nick Holland <***@holland-consulting.net>:

> On 12/29/17 12:00, Michael Hekeler wrote:
> ...
> > 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
Raw Message
On Fri, Dec 29, 2017 at 10:44:44AM +0100, Michael Hekeler wrote:
> 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
Raw Message
On 2017-12-29 10.44.44 +0100, Michael Hekeler wrote:
> 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
Raw Message
On 12/29/17 17:20, Mike Burns wrote:

> On 2017-12-29 10.44.44 +0100, Michael Hekeler wrote:
>> 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
Raw Message
> 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
Raw Message
On 2017-12-29 18.38.17 +0100, Michael Hekeler wrote:
> > 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

It cannot, no. That might be better handled by e.g. chef, ansible,
puppet, etc.
Loading...