Re: Config-/Dotfiles in CVS

[Michael Hekeler]

Am Fri, 29 Dec 2017 22:56:59 -0500
schrieb Nick Holland :

> 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

Re: Config-/Dotfiles in CVS

[Nick Holland]

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.

Re: Config-/Dotfiles in CVS

[Mike Burns]

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.

Re: Config-/Dotfiles in CVS

[Michael Hekeler]

> 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

Re: Config-/Dotfiles in CVS

[Christian Groessler]

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

Re: Config-/Dotfiles in CVS

[Michael Hekeler]

Am Fri, 29 Dec 2017 12:31:12 +0100
schrieb Ingo Schwarze :

> 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.

Re: Config-/Dotfiles in CVS

[Mike Burns]

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.)

Re: Config-/Dotfiles in CVS

[john slee]

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  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
>
>

Re: Config-/Dotfiles in CVS

[Robert Peichaer]

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.

Re: Config-/Dotfiles in CVS

[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