Tue, Jan 17, 2006 at 11:54:03AM -0500, Jason Martin wrote:
Has anyone had any good / bad experiences when using a revision
control system (cvs, arch, subversion, etc) to store CFEngine
configuration? I know CVS is rather picky about adding /
deleting directories, and was wondering what experiences others
have had with various systems.

Mmm, combining two of my favourite toys -- revision control and automated
systems administration. <grin>

We use the baz branch of GNU Arch to revision control our cfengine configs.
I love distributed revision control in general, but what makes svn and CVS
completely useless for our purposes in this case is that we've got multiple
disconnected repositories for different clients and systems, and a common
"trunk" which stores classes, config files, and scripts which are common to
all of our clients.

So, we're currently working on a lighttpd class, which will manage
more-or-less everything related to our deployment of lighty/FCGI systems for
running Rails apps. Within an hour of having completed that, I'll have
pulled those changes (maybe a dozen changesets) into our global trunk, and
it'll be available for other client sites to merge into their repositories.

At the same time, I *don't* pull changes from client to trunk which are
either (a) local config (machine-specific config, stuff that's not
appropriate for global distribution), or (b) not ready for prime-time yet.

GNU Arch's superior changeset tracking makes this stuff pretty
straightforward -- I can, at any time, ask trunk what it's missing from any
particular client, and I can ask a client what it's missing from the trunk,
and merge the various changes back and forth, or record that I don't want a
particular changeset moved.

If you're only managing one infrastructure, and will only ever be managing
one, subversion is probably a passable choice for managing your cfengine
config. I certainly wouldn't recommend CVS in any circumstance other than
for compatibility with legacy systems, and that doesn't appear to be the
case for you.

I would *certainly* recommend using a revision control system for *any* size
cfengine deployment -- there's just too much useful info that an RCS stores,
along with the opportunity to keep track of when, why, and by whom a change
was made. There's also no fundamental incompatibility between what an RCS
can do and what cfengine needs.

course, we're available on a commercial basis to help you set any or all
of this sort of thing up if you need it. <grin>
- Matt

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Wed, Jan 18, 2006 at 08:03:22AM +1100, Matthew Palmer wrote:
Tue, Jan 17, 2006 at 11:54:03AM -0500, Jason Martin wrote:
Has anyone had any good / bad experiences when using a revision
control system (cvs, arch, subversion, etc) to store CFEngine
configuration? I know CVS is rather picky about adding /
deleting directories, and was wondering what experiences others
have had with various systems.

Mmm, combining two of my favourite toys -- revision control and automated
systems administration. <grin>

We use the baz branch of GNU Arch to revision control our cfengine configs.

Yay! Another Arch user, and doing the same thing I do. ;]

A global main trunk, and branches for client specifics.

Russell

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

I use svn as well.

Atom, do you use svn update or export to push the cf config?

right now, I'm using "svn update" which leaves the .svn folders to get
copied out. How are you handling that?

Jason

Atom Powers wrote:

>Highly recommended and easy to do.
>
>I've been using SVN for my repository for several months. I love it.
>The only problem I've run into is one time when I changed the location
>of my repository and had to manually change my update.conf on each
>sysntem to point to the new location (so it could download a new
>update.conf).
>
>I know others have used CVS etc.
>
1/17/06, Jason Martin <jhmartin (AT) toger (DOT) uswrote:

>
>>Has anyone had any good / bad experiences when using a revision
>>control system (cvs, arch, subversion, etc) to store CFEngine
>>configuration? I know CVS is rather picky about adding /
>>deleting directories, and was wondering what experiences others
>>have had with various systems.
>>
>>Thank you,
Jason Martin

>>This message is PGP/MIME signed.
>>
>
>>

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Tue Jan 17, 2006 at 11:54:03 -0500, Jason Martin wrote:
>Has anyone had any good / bad experiences when using a revision
>control system (cvs, arch, subversion, etc) to store CFEngine
>configuration? I know CVS is rather picky about adding /
>deleting directories, and was wondering what experiences others
>have had with various systems.

I use Subversion for storing it all, and push out to the cf master using
rsync. All the magic is done with a makefile.

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Tue Jan 17, 2006 at 17:37:23 -0500, Scott Lackey wrote:
I' ve had a pretty good experience using CVS, except when changes get
>merged, that always breaks something and causes a headache, so if you have
>multiple admins accessing the same configs, this could cause a problem. SVN
>is generally better because it has "truly atomic commits" that use the
>features of the filesystem to ensure locks and whatnot. The main problem
>with this, though, is that SVN requries that you not use an NFS or otherwise
>shared partition. It has to be a "real" ufs, ext3 etc partition, which
>ruled it out for me more than once. I usually just use CVS and hope for the
>best.

rly?

shop has 5 techs working off of NFS, using subversion, each with their
cfinputs working copy in their home directories. Committing can sometimes
be slow due to locking, but it's always worked.

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Tue, Jan 17, 2006 at 11:54:03AM -0500, Jason Martin wrote:
Has anyone had any good / bad experiences when using a revision
control system (cvs, arch, subversion, etc) to store CFEngine
configuration? I know CVS is rather picky about adding /
deleting directories, and was wondering what experiences others
have had with various systems.

I use CVS to store Cfengine's config, and have Cfengine use CVSup
(http://cvsup.org) to get it out of CVS.

The important thing to remember about CVS is that it's based
on RCS, so it doesn't version directories (as well as the other usual
RCS caveats, like no real atomic "rename" command, and all files are
versioned independently).

The usual convention is to remove all files from a directory if you don't
want it to appear, and use the "prune" option when doing updates.
If you are using CVS export, update with the "-dP" options, or
CVSup, then it works fine.

If I was starting from scratch, I'd probably try to go with Subversion,
since I really believe the atomic commits, rename etc. features are
a good idea, although I must say that CVSup is really the ideal way to
get both of the benefits of an export and an update. I am
not sure if there is anything equivalent to extract files from
Subversion's database without having a real workspace, or
waiting for a full export.

I've been using CVS and CVSup for years before the Subversion project
started, so that's part of why I'm still on it I'm sure :)

Thanks,
Rob

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Tue Jan 17, 2006 at 22:11:04 -0800, Robert Helmer wrote:
>If I was starting from scratch, I'd probably try to go with Subversion,
>since I really believe the atomic commits, rename etc. features are
>a good idea, although I must say that CVSup is really the ideal way to
>get both of the benefits of an export and an update. I am
>not sure if there is anything equivalent to extract files from
>Subversion's database without having a real workspace, or
>waiting for a full export.

I'm not a fan of having cvs/svn/etc update the cfinputs directory
automatically. We deliberately chose to use rsync to roll out the cfinputs
manually, so that the cfmaster never has access to the repository directly.

This means you can control access to who can make things go live using SSH
keys, but still let minions check things in, and you also make sure that if
the server is compromised then the repository won't be (necessarily).

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

rsync is breaks cfengine's principle of autonomous control. At the very
least one should use copy to preserve the autonomous model

M

Wed, 2006-01-18 at 17:40 +1100, Jamie Wilkinson wrote:
Tue Jan 17, 2006 at 22:11:04 -0800, Robert Helmer wrote:
>If I was starting from scratch, I'd probably try to go with Subversion,
>since I really believe the atomic commits, rename etc. features are
>a good idea, although I must say that CVSup is really the ideal way to
>get both of the benefits of an export and an update. I am
>not sure if there is anything equivalent to extract files from
>Subversion's database without having a real workspace, or
>waiting for a full export.

I'm not a fan of having cvs/svn/etc update the cfinputs directory
automatically. We deliberately chose to use rsync to roll out the cfinputs
manually, so that the cfmaster never has access to the repository directly.

This means you can control access to who can make things go live using SSH
keys, but still let minions check things in, and you also make sure that if
the server is compromised then the repository won't be (necessarily).

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Wed Jan 18, 2006 at 07:58:48 +0100, Mark Burgess wrote:
>
>rsync is breaks cfengine's principle of autonomous control. At the very
>least one should use copy to preserve the autonomous model

I don't think you understand: we use rsync to roll out the CFINPUTS from our
working copies of the RCS out to the cfmaster. We let cfservd and
update.conf take care of getting them from there to the clients, so the
autonomous model is not broken.

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

, because you have a firewall or something and the admin won't open a
port? I see. The initial push still breaks the autonomy of the master,
but sometimes one doesn't have a choice. Thanks.

M

Wed, 2006-01-18 at 18:11 +1100, Jamie Wilkinson wrote:
Wed Jan 18, 2006 at 07:58:48 +0100, Mark Burgess wrote:
>
>rsync is breaks cfengine's principle of autonomous control. At the very
>least one should use copy to preserve the autonomous model

I don't think you understand: we use rsync to roll out the CFINPUTS from our
working copies of the RCS out to the cfmaster. We let cfservd and
update.conf take care of getting them from there to the clients, so the
autonomous model is not broken.

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Jamie Wilkinson wrote:

Tue Jan 17, 2006 at 22:11:04 -0800, Robert Helmer wrote:

>
>>If I was starting from scratch, I'd probably try to go with Subversion,
>>since I really believe the atomic commits, rename etc. features are
>>a good idea, although I must say that CVSup is really the ideal way to
>>get both of the benefits of an export and an update. I am
>>not sure if there is anything equivalent to extract files from
>>Subversion's database without having a real workspace, or
>>waiting for a full export.
>
>>
>
>I'm not a fan of having cvs/svn/etc update the cfinputs directory
>automatically. We deliberately chose to use rsync to roll out the cfinputs
>manually, so that the cfmaster never has access to the repository directly.
>
>This means you can control access to who can make things go live using SSH
>keys, but still let minions check things in, and you also make sure that if
>the server is compromised then the repository won't be (necessarily).
>

You can set up a read-only svn account to handle downloading the
cfinputs from svn.

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org

Bas van der Vlies wrote:

Jason Edgecombe wrote:
>
>I use svn as well.
>>
>Atom, do you use svn update or export to push the cf config?
>>
>right now, I'm using "svn update" which leaves the .svn folders to
>get copied out. How are you handling that?
>>
in the copy statement (update.conf):
ignore=.svn

Thanks!

Help-cfengine mailing list
Help-cfengine (AT) gnu (DOT) org