1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
|
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.
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 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'}
Mark Burgess
12/12/97
|
