CFENGINE
--------

Cfengine is a tool for setting up and maintaining BSD and System-5-like
operating system optionally attached to a TCP/IP network.  You can think
of cfengine as a very high level language---much higher level than Perl
or shell: a single statement can result in many hundreds of operations
being performed on multiple hosts. Cfengine is good at performing a lot
of common system administration tasks, and allows you to build on its
strengths with your own scripts. You can also use it as a netwide
front-end for @code{cron}.  Once you have set up cfengine, you'll be
free to use your time being like a human being, instead of playing R2-D2
with the system.

The main purpose of cfengine is to allow you to create a single, central
system configuration which will define how every host on your network
should be configured in an intuitive way.  An interpreter runs on every
host on your network and parses the master file (or file-set); the
configuration of each host is checked against this file and then, if you
request it, any deviations from the defined configuration are fixed
automatically.  You do not have to mention every host specifically by
name in order to configure them : instead you can refer to the
properties which distinguish hosts from one another.  Cfengine uses a
flexible system of ``classes'' which helps you to single out a specific
group of hosts with a single statement.

Cfengine is written and maintained by Mark Burgess, who is very glad to
receive all of the feeback about cfengine, but has less and less time
to work on cfengine.

Bug reports to bug-cfengine@prep.ai.mit.edu (News: gnu.cfengine.bug)
General help to help-cfengine@prep.ai.mit.edu (News: gnu.cfengine.help)
Info & fixes at http://www.iu.hioslo.no/~mark/cfengine.html

INSTALLATION
------------

To compile this program you simply change to this directory  and type:

configure
make

The usual GNU rules apply for compilation from a different directory,
namely

configure --prefix=/local/gnu
make
make install

will configure the installation so that bin and lib directories
are placed relative to /local/gnu instead of the default /usr/local.
If you want to build from a different directory than the one
in which this file resides, you use:

/path/configure --srcdir=/path/to/the/directory/you/are/reading/now
make -f /path/to/the/directory/you/are/reading/now/Makefile

If you have a reasonably complete installation of one of the
supported operating systems, you should not have any problem
compiling the software.

Bug reports/info/comments to: bug-cfengine@gnu.ai.mit.edu

Latest update news on: http://www.iu.hioslo.no/~mark/cfengine.html

Latest patches: ftp.iu.hioslo.no

I reply to all messages that are sent to me, but occasionally I get
messages which I cannot reply to because of errors in the
return address. If you don't receive a reply within a couple of
weeks, then you should assume that I was unable to do so.

PROBLEMS FINDING SHARED LIBRARIES
----------------------------------

The auto configure script is not smart enough to find shared
libraries which do not have a corresponding archive library (.a).
This applies to solaris machines with libthread and libdce for
instance. If configure reports that you do not have these libraries
you need to edit the file config.cache after configure has run
and change 'no' to 'yes' for the relevant libraries, then
do a make.


INSTALLING A NEW VERSION / UPGRADING
------------------------------------

Cfengine does not compile any names based on your choice of
prefix into its code, so when you collect a new version, you
don't *have* to compile with the correct prefix and run
make install. It should be sufficient to do:

configure
make
cp src/cfengine DESTINATION

Version 1.4 and beyond
-----------------------

In this version of cfengine, it is useful to have the tcp-wrappers package
in order to secure access control for network services.

Note that some linux and NetBSD systems have corrupt TCPwrapper libraries
(libwrap) which create unresolved function references at *RUN TIME*
but which appear to compile correctly. Test your compilation before
installing by writing

  src/cfengine -p -v

If you experience this problem, try removing the -lwrap option from
the Makefile and undefining HAVE_TCPD_H, HAVE_LIBWRAP.


NOTE 1.4.*
-----------

 Before installing this verison, add the following line to your /etc/services
 file

  cfengine        5308/tcp


PROBLEMS/TROUBLESHOOTING
------------------------

Although every effort has been made to make the compilation of cfengine
trouble free, you might still encounter some problems where non-standard
features are concerned. The differences between systems is still a major
headache.

It is known, for instance, that versions of gcc after 2.7.0 have a malloc
bug which causes a segmentation fault during parsing. This will not
necessarily show up on all systems. It appears to affect solaris.XF

Earlier versions of the GNU/Linux operating system do not have support
for some of the facilities which cfengine uses.  In particular, the
ability to use NIS netgroups is absent from earlier versions.  During
the installation procedure, the @code{configure} script tests for this
possibility and advises you if the facility cannot be used.  You can
still use cfengine in this case but netgroups will not be expanded.
Another problem with GNU/Linux concerns a special socket call to the
TCP/IP network interface.  This is a command which configures the static
routing table and appears to be absent from all versions of Linux and
newer IRIX versions.  There are also problems with NetBSD.  These
features are undocumented and will be fixed as soon as they have been
understood! If you are running in verbose mode a warning message is
printed, otherwise cfengine will ignore attempts to set a default route
on the system.


A number of users have experienced a problem using flex and bison
in place of lex and yacc. There appears to be a bug in one of these
programs which causes cfengine to compile correctly but misinterpret
its configuration files, generating an error of the form

cfengine:10:action contains invalid statement

for every line! The cure is to collect the latest versions
of flex and bison from your nearest GNU site.

On really old systems, the configure program is not able to guess
what kind of system you are working on. This is true of SunOS 
versions 4.0.* and also of BSD 4.3 systems. In such cases, you might
be able to compile cfengine by using the autoconf option `host'
to specify the host-type.

configure --host=sparc-sun-sunos4.0

Some other systems which will compile if forced are:

m68k-hp-bsd4.3
?-?-bsd4.3
romp-ibm-aos
?-?-aos

On BSDI systems, the configure program fails due to differences
in the shell. Here is a fix, straight from the horses mouth!
==BEGIN=====================

Mark,

   To correct this for BSDI I replaced the following script fragment from
configure:

-------------------------------------------------------------------------
#
# Add to the default list of places in LDFLAGS to compensate for
# ... the configure default value of LIBS on some systems
#
for x in /usr/local/gnu/lib /usr/local/gnulib /usr/local/lib /usr/lib /lib
do
  if test -d "$x"; then
    y=`expr match "$LDFLAGS" ".*-L$x"`
    if test $y -eq 0; then
      LDFLAGS="$LDFLAGS -L$x"
    fi
  fi
done

#
# Add to the default list of places in CPPFLAGS to match LDFLAGS above
#
for x in /usr/include /usr/local/gnu/include /usr/local/include
do
  if test -d "$x"; then
    y=`expr match "$CPPFLAGS" ".*-I$x"`
    if test $y -eq 0; then
      CPPFLAGS="$CPPFLAGS -I$x"
    fi
  fi 
done
------------------------------------------------------------------------

   With this script fragment, which successfully executed:

------------------------------------------------------------------------

#
# Add to the default list of places in LDFLAGS to compensate for
# ... the configure default value of LIBS on some systems
#
for x in /usr/local/gnu/lib /usr/local/gnulib /usr/local/lib /usr/lib /lib
do
  if test -d "$x"; then
    case $LDFLAGS in
    .*-L$x)
      LDFLAGS="$LDFLAGS -L$x"
      ;;
    esac
  fi
done
   
#
# Add to the default list of places in CPPFLAGS to match LDFLAGS above
#
for x in /usr/include /usr/local/gnu/include /usr/local/include
do
  if test -d "$x"; then
    case $CPPFLAGS in
    .*-I$x)
      CPPFLAGS="$CPPFLAGS -I$x"
      ;;
    esac
  fi
done
-----------------------------------------------------------------------


==END=======================

On some systems, problems arise when using flex. Flex might
generate a lexer file lex.yy.c which defines malloc or some other
function to be of a type which conflicts with the system definition.
If you obtain such a culture crash, edit the lexer file manually
and simply delete the offending definitions, then run make again.

As of version 1.4.0 cfengine tries to link in features based on the
Berkeley database library @file{libdb} and the TCP wrappers library
@file{libwrap}.  If you want to use these facilities, you will have to
collect them and install them before compiling cfengine.  Some
problems have been experienced with the linux version of TCP
wrappers. If you experience compilation problems, the best thing to do
is to edit @file{src/conf.h} after configuration and remove the line
beginning @samp{#define HAVE_LIBWRAP}.

Newer solaris systems have ACLs. The ACL features only matured in version
2.5 of solaris however, and there have been some problems with the
partial implementation in 2.4. If you obtain error messages about unknown
ACL functions, edit the @file{config.cache} file in the cfengine root
directory and set the value:

ac_cv_header_sys_acl_h=${ac_cv_header_sys_acl_h='no'}


If you use the DCE (Distributed computing environment) cfengine will try to
compile the ACL extension for DFS. This requires the DCE library to be present
on the system on which you are compiling. On some systems it also requires
thread libraries to be present. Unfortunately, the autoconf program
which generates the Makefiles cannot detect shared libraries, only archive
libraries. This means that you need to edit the @file{config.cache} file
to compile in this support. Set the following values:

ac_cv_lib_dce_main=${ac_cv_lib_dce_main='yes'}
ac_cv_lib_dce_main=${ac_cv_lib_thread_main='yes'}


--------------------------------------------------------------------

Problems compiling on IRIX

Subject: [1.4.10] with gcc-2.8.0 on irix6.x
    Date: 24 Feb 1998 16:53:02 GMT
      To: gnu-cfengine-bug@prep.ai.mit.edu


gcc-2.8.0 produces '-n32' formatted object files, which need to be linked
with libraries in /usr/lib32.  The linker finds /usr/lib or /usr/lib32
according to the formats it finds, unless an explicit -L/usr/lib is
applied.  For this reason, it is disastreous to add -L/usr/lib as it forces
the linker to take the libraries with -o32 objects

Here is a rough-and-ready patch which got 1.4.9 and 1.4.10 to build
properly for me.

--- benedict

--- cfengine-1.4.9.orig/configure.in	Wed Dec 24 11:43:45 1997
+++ cfengine-1.4.9/configure.in	Wed Feb  4 09:33:24 1998
@@ -16,7 +16,7 @@
 # Add to the default list of places in LDFLAGS to compensate for
 # ... the configure default value of LIBS on some systems
 #
-for x in /usr/local/gnu/lib /usr/local/gnulib /usr/local/lib /usr/lib /lib
+for x in /usr/local/gnu/lib /usr/local/gnulib /usr/local/lib
 do
   if test -d "$x"; then
     y=`expr match "$LDFLAGS" ".*-L$x"`

--
Benedict Lofstedt     <blofstedt@daimi.aau.dk>
Computer Science Department, Aarhus University,   Fax: + 45 8942 3255
Ny Munkegade, DK-8000 Aarhus C, Denmark.        Phone: + 45 8942 3222


Mark Burgess

12/12/97

