[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: cfengine and revision control

From: Luke Youngblood
Subject: RE: cfengine and revision control
Date: Mon, 9 May 2005 21:33:52 -0400

I read your discussion link before I did my setup, and was put off a little
bit by the strange hostnames (no offense intended, but it's much easier to
understand an example configuration when the hostnames are similar to the
server role, eg. DNS servers are called ns1 and ns2, etc.)  Also, the script
was called!!! :-)

Anyway, I would be very much interested in seeing the scripts you use on the
master server to generate the master overlay for each host.  This seems like
a very nice solution which allows you to verify file integrity for each
server, without having to hand-code a copy statement for each file, and also
not sharing passwd/shadow information with servers in other departments that
shouldn't see that information.


-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of "Sami J. Mäkinen"
Sent: Monday, May 09, 2005 4:21 PM
To: cfengine help list
Subject: Re: cfengine and revision control

Just click on the "discussion" link on that page. :)

Briefly, my setup is (err, was) something like this:

1) Everything is stored in CVS, cfengine inputs as well
    as the "overlay" directory tree that is copied to each host.

2) On the master server, a shell script is responsible of
    cvs update, cvs tagging and rsync-copy excluding the
    CVS metadata directories from the master directory that
    is finally copied to the clients.

3) The master overlay directory is copied (cfengine internal
    or external - rsync) to each client into /etc/NWS/,
    for example.

4) On each client, a special shell script is run.
    It will generate or symlink the files according to the
    hints found in the overlay directory hierarchy.

Recent development has moved the whole customization
process into the master server. The overlay directory
is generated for each individual host separately.

This way, you cannot see other host's configurations
(/etc/sudoers, passwd etc) on every host even if you
can get a root shell. Less information leakage.

Please contact me if you want me to contribute. :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]