Re: processing order, preprocessing, etc.

[Thomas Glanzmann]

> But maybe your idea of installation was different from what I had in
> mind.  I was imagining things like rpm or pkg_add or apt-get where you
> mainly have to feed them package names and they will do their things.

Same for us.

we have the following facility:

cfagent.conf:

control:
...
        solaris::
                cipos  = ( "solaris" )
...
        linux::
                cipos  = ( "linux" )
...
shellcommands:
                "/var/cfengine/inputs/update $(cipos)"
...

update:

#!/bin/bash
# $Header: /var/cfengine/inputs/RCS/update,v 1.38 2002/12/21 11:20:25 simigern 
Exp $

# OS specific Part
case $1 in
        linux) #--[LINUX]------------------------------------------------------
        export 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11

        apt-get remove cfengine lilo fcron mozilla-mailnews mozilla-browser 
mozilla-psm mozilla postgresql-client libpgsql2 cdrdao

        /usr/bin/dpkg --set-selections < /var/cfengine/inputs/selections
        /usr/bin/apt-get update
        /usr/bin/yes '' | /usr/bin/apt-get dselect-upgrade
        /usr/bin/yes '' | /usr/bin/apt-get upgrade
        /usr/bin/apt-get clean
        yes '' | dpkg --configure -a

        ;;
        
        solaris) #--[SOLARIS]---------------------------------------------------

        MAILTO="autopatch@cip.informatik.uni-erlangen.de"
        LEVEL="silent"

        export PATH=/bin:/sbin:/usr/bin:/usr/sbin

        chmod 1777 /tmp

        if [ "zz$2" = "zzautopatch" -o -f "/FAU_firstboot" ]; then
          echo "Starting autopatch... (this may take a while >= 30mins on new 
installs)"
          /proj/Patches/bin/autopatch "$MAILTO" "$LEVEL"

          if [ "`cat /+private/local/adm/patchversion`" = "74" ]; then
            echo 75 >/+private/local/adm/patchversion
            echo "Resuming autopatch..."
            /proj/Patches/bin/autopatch "$MAILTO" "$LEVEL"
          fi
        fi

        if [ -f "/+private/local/adm/patchlog" ]; then
          ( echo "Subject: Patch report for `/bin/hostname`"
            echo
            cat "/+private/local/adm/patchlog" ) | /usr/bin/mail "$MAILTO" && 
rm "/+private/local/adm/patchlog"
        fi

        if [ ! -f "/etc/ssh/ssh_host_dsa_key" ]; then
          pkgrm -n SUNWsshcu SUNWsshdr SUNWsshdu SUNWsshr SUNWsshu
          pkgadd -n -d ~sithglan/work/openssh/openssh-3.4p1 CIPopenssh
          /etc/init.d/sshd stop
          /etc/init.d/sshd start
        fi

        ;;

        *)
                echo ERROR: unknow arch $1;
        ;;
esac

# Host specific Part

case `/bin/hostname` in
        faui04a)
                # SunRay Server Software is broken
                rm -rf /etc/rc0.d/K98utsvc /etc/rc0.d/K72dsserv 
/etc/rc0.d/K86dsadm
        ;;
esac

# Generic Part
>From luke@madstop.com Sun Dec 22 21:18:16 2002
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13)
        id 18QIAV-0005GC-00
        for help-cfengine@gnu.org; Sun, 22 Dec 2002 21:18:11 -0500
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13)
        id 18QI9L-0004IH-00
        for help-cfengine@gnu.org; Sun, 22 Dec 2002 21:17:01 -0500
Received: from [207.65.26.13] (helo=pixie.madstop.com)
        by monty-python.gnu.org with esmtp (Exim 4.10.13)
        id 18QI9J-0004CW-00
        for help-cfengine@gnu.org; Sun, 22 Dec 2002 21:16:57 -0500
Received: from localhost (luke@localhost)
        by pixie.madstop.com (8.11.6+Sun/8.11.6) with ESMTP id gBN2Gqw25732
        for <help-cfengine@gnu.org>; Sun, 22 Dec 2002 20:16:52 -0600 (CST)
Date: Sun, 22 Dec 2002 20:16:52 -0600 (CST)
From: "Luke A. Kanies" <luke@madstop.com>
X-Sender: luke@pixie
To: help-cfengine@gnu.org
In-Reply-To: <84vg1l97ly.fsf@lucy.cs.uni-dortmund.de>
Message-ID: <Pine.GSO.4.10.10212222011370.25691-100000@pixie>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Subject: Re: processing order, preprocessing, etc.
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: Mon, 23 Dec 2002 02:18:17 -0000

On Sun, 22 Dec 2002, Kai Gro=DFjohann wrote:

> "Luke A. Kanies" <luke@madstop.com> writes:
>=20
> > Because then cfengine isn't in charge of making sure everything looks t=
he
> > way it's supposed to.  My goal is to keep all of the configuration data=
 in
> > the cfengine configs, and as much as possible of the methods in there a=
lso
> > (the installation method might be as simple as setting a set of files t=
o
> > be pulled down).
>=20
> Well, my thought was to distribute the script and its config files
> with cfengine.  So you still have a central location to fix things.
> And does it really matter whether the files you edit centrally are in
> cfengine syntax or another syntax?
>=20
> But maybe your idea of installation was different from what I had in
> mind.  I was imagining things like rpm or pkg_add or apt-get where you
> mainly have to feed them package names and they will do their things.

Yeah, I was thinking more along the lines of Tobias Oetiker's
TemplateTree; rather than use the native package format, I would just have
cfengine copy the files over, and I guess perform any necessary post/pre
install functions.

The difference between having cfengine (or whatever your configuration
tool is) do the work, versus using the package tools is that 1) you are
using the same toolset on all of your platforms, and 2) you get all the
benefits that cfengine provides, like checksumming, replacing files with a
dist version, etc.

But one of the other main differences is that if I use my configuration
tool (cfengine, in this case) to do, or at least initiate, all the work,
then that's one place that my admins need to go to figure out what a host
looks like.  In fact, one of the reasons I am so interested in splitting
the various types of data (package version, package list, install methods)
apart is because you are usually not interested in all three at once; I
may want to know what packages are installed on a given host, or what the
default packages are, but I don't usually need all that information at
once.  That makes it much easier to get more useful information at a
glance, and system administration is hard enough without making it harder
by storing host info in ten different places.

Not to say that I expect to reach perfection, but I want to know what I
can do before I compromise, rather than after. :)

Luke

--=20
"The optimist proclaims that we live in the best of all possible worlds,
and the pessimist fears that this is true."
                -- James Branch Cabell 1879-1958