[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Modular configuration bundles (was: Re: shellcommand return-value define
From: |
Mark R. Lindsey |
Subject: |
Modular configuration bundles (was: Re: shellcommand return-value defines) |
Date: |
Thu, 21 Sep 2000 20:20:39 -0400 |
: > Specifically, I (1) perform
: > some editfiles, then (2) need to check to see if the edited files have
: > a specific property, and define a class if they have that property.
: >
: Never tried it, but you might be able to use a module. Have the module
: (written in shell or perl) run the command and interpret the exit
: status. When it's ready, have it define the necessary class by printing
: it out with a + in front. Modules are mentioned in the Tutorial.
Eh; maybe I'm not really using cfengine the way it was intended . . .
Modules really don't do what I want, either, since a module can't
attach itself to a class the way that a shellcommands or an editfiles
can. Consider my several goals:
(1) I want to be able to guarantee that the installed
configuration files on any system are precisely what I have
specified via cfengine (i.e., local edits don't stay around)
(2) I want to define groups of machines that should configure
specific services
(3) I want to reload or restart a service when its
configuration files have changed, but at no other time
(4) I want to separate the tasks necessary to configure
a program or service so that, for example, the steps
necessary to configure an NIS Server are not mixed in
with the steps to configure a web server.
I'd like to think that I could do this neatly with cfengine. First
I define some groups of machines that do certain jobs, just like
the cfengine examples suggest:
groups:
NISServer = ( postel )
WWWServer = ( stevens )
Then this general-purpose action sequence is supposed to walk
though the general steps of configuring any service:
control: actionsequence = (
## This copies a bunch of original operating system
## files to a working directory
copy.setup_work_directory
## This step edits the working directory's files,
## making site and system-specific changes
editfiles.customize_configuration
## This step compares the working directory to
## the actual system files, to determine what's going
## to be copied
##
## I have yet to determine how to do this.
???.check_for_changes_in_configuration
## This step recursively copies from the working
## directory to the system any files that have
## changed
copy.install_configuration
## This step restarts any services that have new
## configurations; for example, if /etc/inetd.conf
## was changed in the previous step, then this step
## should send a SIGHUP to inetd
shellcommands.reload_changed_configurations
)
Configuration bundles, like this one for NIS Servers, can then
hook on to the temporarily-defined classes to do application-specific
chores. I want to keep all of the NIS-Server-specific things in this
one file:
#####
## NIS Server configuration bundle
##
editfiles: customize_configuration.NISServer::
{
$(working_directory)/var/yp/securenets
Append "255.255.255.0 10.10.3.0"
}
???: check_for_changes_in_configuration.NISServer
## This needs to define the class
## NISServer_needs_reloading
## if /var/yp/securenets differs from
## $(working_directory)/var/yp/securenets
...
define=NISServer_needs_reloading
shellcommands: reload_changed_configurations.NISServer_needs_reloading::
"/etc/rc.d/init.d/ypserv reload"
## End of NIS Server configuration bundle
#####
And I import all of the configuration bundles:
import:
cf.NISServer
cf.NISParticipant
cf.WWWServer
cf.FTPServer
cf.MailServer
Each of these bundles is unaware of any of the other bundles. Each bundle
just implements a set of actions, like those shown for the NISServer
group above, so that the correct machines run the correct actions.
My current problem is figuring out how to implement
check_for_changes_in_configuration such that I can define
NISServer_needs_reloading if its file has changed.
The apparent way would be to use a copyfiles action on the specific
file -- /var/yp/securenets -- and define NISServer_needs_reloading if
it's copied. This might work for NIS, but it won't always work where
multiple groups use the same file.
Consider an example: both SSHServer and FTPServer modify /etc/inetd.conf.
If we have in the SSHServer bundle
copy: install_configuration.SSHServer::
$(work_directory)/etc/inetd.conf dest=/etc/inetd.conf
define=SSHServer_needs_reloading
and also, in the FTPServer bundle
copy: install_configuration.FTPServer::
$(work_directory)/etc/inetd.conf dest=/etc/inetd.conf
define=FTPServer_needs_reloading
then we have a race condition. When the /etc/inetd.conf changes, BOTH
SSHServer_needs_reloading
and
FTPServer_needs_reloading
should be defined, so that the appropriate reloads can be done. When
copy:install_configuration.SSHServer
copies the file first, it will define SSHServer_needs_reloading. Then
copy:install_configuration.FTPServer
will not be able to detect that the configuration file has changed,
because $(work_directory)/etc/inetd.conf is the same as /etc/inetd.conf
Feh. :(
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Modular configuration bundles (was: Re: shellcommand return-value defines),
Mark R. Lindsey <=