We have a similar situation in our shop; the bulk of the policy is set
in a main office, but satellite shops have the ability to add to it.
Here's how I have it set up:
The master server contains authoritative copies of most of the files,
and the local cfengine ("slave") servers pull copies directly from the
master for redistiribution to their clients. One file that is *not*
copied is cf.site. The cf.site file is required to be valid and exist,
but that's it-- local admins can put whatever they want in there and do
not need to fear it being stepped on from On High. (At the master site,
the cf.site file is used for local policy as well as holding things like
encrypted passwords that the remote admins have no need to see.)
It is generally used to include a bunch of other local-to-the-site files
that perform various functions.
Martin, Jason H wrote:
The problem is that root on the CFE master server could bypass all of
that. I'm confident that there are very straightforward ways to stop
non-CFE-master-root users from wreaking havoc, but then there is the
'root' problem.
I'm thinking that a two-server system under different administrative
domains such that the servers have to agree on the rules and repository
before changes are applied sounds about right.
-Jason Martin
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Jeremy Mates
Sent: Thursday, October 13, 2005 10:58 AM
To: [email protected]
Subject: change control via CVS tags
* Martin, Jason H <[EMAIL PROTECTED]>
Along the same lines, has anyone implemented a system such
that there
is no one person capable of pushing out changes? I'm
talking about a
system analogous to the nuclear missile keys that require 2
people to
agree to launch.
One approach would be to store all the configuration under
CVS, then use a taginfo script to restrict who can apply tags
to a file[1]. This way, anyone with CVS rights could commit
files, but only certain people would have tag rights.
CFEngine would then pull from CVS only files with a certain
tag set[2].
Some extra logic in the taginfo script might ensure the same
person could not both commit and tag the file, though I have
not looked at how hard this would be. Linking all this to an
approval ticket system for SOX compliance would be even more fun...
[1] CVSPermissions is close, but uses the directory
permissions for tag
rights as well: http://sarovar.org/projects/cvspermissions
[2] stage-from-cvs is one method: http://sial.org/howto/cvs-tips/#s4
_______________________________________________
Help-cfengine mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-> cfengine
_______________________________________________
Help-cfengine mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-cfengine
_______________________________________________
Help-cfengine mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-cfengine
