Re: cfengine 2.0.4 installation problem

[Thomas Glanzmann]

In article <mailman.431.1040318427.19936.help-cfengine@gnu.org>, Thomas 
Glanzmann wrote:
>> I tried on Solaris with openssl that i compiled myself.
> 
>> 1) Is it possible to compile openssl not to use shared libraries ?
>> 2) Can you tell me maybe how to tell the configure script manually that 
>> openssl is ok and continue ?
> 
> a static openssl and berkleydb version in it. Last time I tried to compile the
> whole thing under solaris it crashed.
tried to link the whole thing __statically__. The version I provided works
fine.
>From gnu-help-cfengine@m.gmane.org Sat Dec 21 15:38:41 2002
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13)
        id 18PqOP-0002Th-00
        for help-cfengine@gnu.org; Sat, 21 Dec 2002 15:38:41 -0500
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13)
        id 18PqOM-0002Ol-00
        for help-cfengine@gnu.org; Sat, 21 Dec 2002 15:38:40 -0500
Received: from main.gmane.org ([80.91.224.249])
        by monty-python.gnu.org with esmtp (Exim 4.10.13)
        id 18PqOM-0002KU-00
        for help-cfengine@gnu.org; Sat, 21 Dec 2002 15:38:38 -0500
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
        id 18PqNo-0007VM-00
        for <help-cfengine@gnu.org>; Sat, 21 Dec 2002 21:38:04 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: help-cfengine@gnu.org
Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
        id 18PqNO-0007Tl-00
        for <gmane-comp-sysutils-cfengine-general@m.gmane.org>;
        Sat, 21 Dec 2002 21:37:38 +0100
Path: not-for-mail
From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
Date: Sat, 21 Dec 2002 21:38:09 +0100
Organization: University of Dortmund, Germany
Lines: 37
Message-ID: <84ptrv85vy.fsf@lucy.cs.uni-dortmund.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@main.gmane.org
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50
 (i686-pc-linux-gnu)
Cancel-Lock: sha1:icpU7yKwhK8PCpsq1UNi+h/WfeE=
Sender: news <news@main.gmane.org>
Subject: Undo a cfengine action?
X-BeenThere: help-cfengine@gnu.org
X-Mailman-Version: 2.1b5
Precedence: list
List-Id: Users list for GNU cfengine  <help-cfengine.gnu.org>
List-Help: <mailto:help-cfengine-request@gnu.org?subject=help>
List-Post: <mailto:help-cfengine@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/help-cfengine>,
        <mailto:help-cfengine-request@gnu.org?subject=subscribe>
List-Archive: <http://mail.gnu.org/pipermail/help-cfengine>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/help-cfengine>,
        <mailto:help-cfengine-request@gnu.org?subject=unsubscribe>
X-List-Received-Date: Sat, 21 Dec 2002 20:38:41 -0000

We do lots of things with cfengine, but it occurred to me that it is
kind of difficult to undo the effect.  What do folks do to deal with
this?

Why do I have to undo operations?  Suppose I have a machine which is
the foo server.  Various config files are edited such that they are
good for foo servers.  Now the role of foo server moves to another
machine.  It's easy to change the class in cfagent.conf such that the
necessary actions will be done on the new machine, but how do I make
it so that they are *undone* on the old machine?

What kinds of operations are we talking about?  Well, config files
might be copied to /etc, or certain lines added to config files.

The background of my question is that I think that you guys must have
the same problem in principle.  And obviously, you have some way of
dealing with it.  But how?  What has fared well in practice?

One idea would be to completely scratch and reinstall a machine when
something like this happens.  After all, all the configuration will
be handled by cfengine anyway.

Another idea would be to never rely on default files coming with the
OS.  (Mine is Debian GNU/Linux, fwiw.)  So whenever you have a config
file for foo servers, you also have the same one for non-foo servers.

A third idea would be to construct was_foo_server classes in cfengine
and to have actions to undo the effect in the config.

A fourth idea would be to look through the cfengine config to see
which files are affected.  Then, run the Debian command that
reinstalls the corresponding packages, with an option to overwrite
the config files.

I'm happy about any input.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)