help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modular configuration bundles (was: Re: shellcommand return-val ue d


From: Mark . Burgess
Subject: Re: Modular configuration bundles (was: Re: shellcommand return-val ue defines)
Date: Sun, 1 Oct 2000 23:07:46 +0200 (MET DST)

On 21 Sep, Mark R. Lindsey wrote:
> : > 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. :(
> 

-- 

Sorry for the late reply. I am rather pressed lately, but I think
your problem might be the way cfengine reads imported files
AFTER the main file is parsed. That means the ordering of class
definitions might be an issue. If you are defining classes based
on  the result of a previous action, then you should declare
them all in AddInstallable (control), to make sure that the relevant
actions are installed, otherwise cfengine will be very sensitive
to ordering of commands.

hope this helps,
Mark




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





reply via email to

[Prev in Thread] Current Thread [Next in Thread]