headers
Aaron Bostick | 5 Apr 2004 17:47
Favicon

Configuration management with cfengine

Ok, after having read a thread last week on this topic, I have to give some of
my thoughts on the matter.

As I see it, what we are trying to do in essence is to maintain really sparse
copies of the filesystems for these unix hosts.  These hosts can generally be 
classified by OS and version, role (of which a host can have multiple), and 
there is always a little bit of uniqueness to each host e.g. ip address.

My scheme would create directories for each of the classes above and in those 
directories I would mimic the real filesystem of the target host in the minimal
sense.  These directories could be kept in big cvs/subversion repository or one 
repository per directory, or what I would do, is a repository per environment,
e.g. qa, staging, production, etc.  For example, I might have:

solaris/
  etc/
    hosts
apache/
  etc/
    httpd/
      httpd.conf
postfix/
  etc/
    postfix/
      main.cf

And for a host named server01:

server01/
  etc/
(Continue reading)

Permalink | Reply | 3 comments |
headers
Will Lowe | 7 Apr 2004 23:22

Re: (no subject)

> how anal are most people when it come to checking file
> permissions/ownership/md5sums of all files in a package

Not at all.  It's just not worth the effort for most environments.

"rpm -V", or "debsums" for dpkg folks, can do this.  But IMHO, by the
time you're worried enough to do that, you need to have the md5sums on
read-only media (CDROM, nfs mounted ro, be fetching them by https,
whatever) rather than on local disk.

If I were going to do something like this, I'd probably do it with an
rsync setup (I think systemimager does this?) -- just "rsync
policyhost::/tree /" with some excludes.

--

-- 
					thanks,
		
					Will
Permalink | Reply | 0 comments |
headers
John Sechrest | 1 Apr 2004 20:31

Re: FW: Version control checkout


I see what you are doing, but I am not seeing what advantage it gives from
using tags on a regular cvs tree.

What efficiency / clarity are you getting from seperate cvs trees?

Martin Andrews <martin <at> slackers.net> writes:

 % Instead of  CVS branches I have staged releases. For early level testing 
 % I serve up the config tree from my CVS sandbox. Once I have some level 
 % of confidence I check my changes in and the master checks out the CVS 
 % head and makes a new release. Every time I change my configuration I 
 % create a new unique release tree - so the directory my master publishes 
 % looks like this:
 % 
 % drwxr-xr-x   25 cfmaster cfmaster     4096 Mar 24 14:24 260
 % drwxr-xr-x   25 cfmaster cfmaster     4096 Mar 25 10:03 261
 % drwxr-xr-x   25 cfmaster cfmaster     4096 Mar 26 09:13 262
 % drwxr-xr-x   25 cfmaster cfmaster     4096 Mar 26 10:28 263
 % drwxr-xr-x   25 cfmaster cfmaster     4096 Mar 26 11:24 264
 % drwxr-xr-x   25 cfmaster cfmaster     4096 Mar 31 16:32 265
 % drwxr-xr-x   25 cfmaster cfmaster     4096 Apr  1 10:43 266
 % drwxr-xr-x    3 cfmaster cfmaster     4096 Apr  1 10:43 archive
 % lrwxrwxrwx    1 cfmaster cfmaster        3 Apr  1 10:43 current -> 266
 % -rw-r--r--    1 cfmaster cfmaster        4 Apr  1 10:43 current.num
 % -rw-r--r--    1 cfmaster cfmaster        4 Apr  1 10:43 relnum
 % lrwxrwxrwx    1 cfmaster cfmaster        3 Mar 26 11:35 stable -> 264
 % -rw-r--r--    1 cfmaster cfmaster        4 Mar 26 11:35 stable.num
 % 
 % Most machines check the stable.num at each run and use that release. I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Oetiker | 7 Apr 2004 20:35
Picon
Picon
Favicon

Re: (no subject)

Today Aaron Bostick wrote:

> After seeing Tobi's reply, I read his LISA paper on tetre2.  This seems
> to be a good solution to the problem I am having.  I like the idea of
> preprocessing cfengine config files so I can take advantage of some meta
> information when deploying the filesets (or feature sets as he calls
> them).
>
> I remember reading about tetre2 a while back when I first started using
> cfengine but I didn't really understand the need.  After having used
> cfengine for a good while now, the need becomes apparent.

Aron,

The things I missed in cfengine 1.x (did not look much at 2.x) and
which triggered me to write tetre2, are:

* we use diskless clients, this means I can access there root
  filesystems directly on the server but the client root are located
  in /export/.../client-name ... I wanted the ability to apply
  change sets to these client roots. The same changes I apply to
  standalone servers as well.

* an additional abstraction layer with a defined
  interface between the upper and the lower layer so that the
  highlevel config file must not deal with nitty-gritty details.

another thing is a philosophical difference ... marks idea of
system management is to have a system where machines are sort of
'self healing' cfengine is an implementation of this in the sense
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Wray | 23 Apr 2004 06:19
Picon
Favicon

Re: OS's in CVS (or other versioning systems)

On Friday 23 April 2004 14:09, Harry Hoffman wrote:
> Hi All,
>
> Ok, so for a while now I've heard of people talking about how they
> are keeping their entire OS's in CVS.

I'd be interested as well, only with subversion (svn) instead of cvs.
Theoretically, svn should be able to do sensible things with ownerships 
and permissions. I havn't seen any concrete examples though... it 
doesn't do it by default.

Also, svn does (by default) do sensible things when renaming and 
removing files and directories.

See http://subversion.tigris.org/

> Can anyone provide information/examples of how they are accomplishing
> this. I'm currently in the process of trying to get this done and
> starting to run into all of the potential problems.
>
> Any help, or pointers, would be greatly appreciated!

From what I've seen, trying to manage filesystems where ownership and 
permissions really matter, CVS is hopeless; 

web monkey: "why won't my script run?" 
me: "Did you pull it out of a cvs repository?"
web monkey: "yes... but whats that..."
me: "Check the permissions, its probably lost its exec bits".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ted Spradley | 23 Apr 2004 16:35

Re: OS's in CVS (or other versioning systems)

On Thu, 22 Apr 2004 22:04:17 -0700 (PDT)
Eric Sorenson <eric <at> explosive.net> wrote:

> I'd suggest the problems you're encountering are systemic, and further
> that they stem from the irreducible fact that CVS was not meant to
> contain an operating system. :)

Works reasonably well for FreeBSD, and for NetBSD and OpenBSD as well. 
But I don't think that's what the original poster really had in mind.
Permalink | Reply | 0 comments |
headers
Tobias Oetiker | 7 Apr 2004 23:16
Picon
Picon
Favicon

Re: (no subject)

Aron,

[...]
> Obviously this whole scheme relies on rpm and many people might not like
> that or use that, but if you do I think it would work nicely because it
> gives you complete coverage over all installed files.  Almost tripwire
> like capabilities.  It would be real nice though if rpm could just
> repair the broken pieces of a package instead of the whole thing.
>
> How are other people accomplishing this sort of thing?

My question is, why should these files have the wrong permissions
in the first place ? If you are worried about hackers you might
want to use aida (a free trippwire) ... otherwhise its realy a
matter of managing the package lists of the machines ...

On another note, my philosophy regarding packages is that I use
them mainly for the 'core os' ... ls init xinetd ... stuff that is
very stable ... for production code I mostly compile it my self,
and keep it in a special repository (networked ... but that is
another story) the organisation of the repository allows to install
many versions of the same app in parallel. this allows me to go
quickly back and forth between versions if there is an issue with
an upgrade, and regarding the users of my workstations, I give them
the option to choose which version of a program they want to use
... I can install the latest stuff for the geeks and keep the
people who actually work happy by not constantly changeing their
environment ... http://www.sepp.ee.ethz.ch/

cheers
(Continue reading)

Permalink | Reply | 0 comments |

Gmane