Re: How can I extend the types of configuration managed by cfengine?

[Frank Smith]

Have you considered placing your script (and any associated files)
in the 'files' section to distribute it and using the 'shellcommands'
section to control running it ?  A module might be more elegant, but
shellcommands is a quick and dirty way to integrate existing scripts.

Frank

--On Thursday, September 12, 2002 12:05:12 +1000 Daniel Pittman 
<daniel@rimspace.net> wrote:

> Good day.  I have been using cfengine 2 for a few weeks now and I am
> very pleased with it's general structure and features. While it's still
> taking time to get a grasp on how, exactly, I want to use it, I have
> gotten very positive results so far.
> 
> The once main sticking point that I have today is in working out how to
> manage a handful of configurations with cfengine.
> 
> The primary issue for me, at the moment, is that I run a mailing list
> service which uses an SQL database to manage subscription information.
> 
> As the list software evolves the database schema also changes, requiring
> some administration work on my part. Currently this is managed on the
> database host directly.
> 
> Th two main problems this has, for me, are that maintenance of the
> schema by hand is a time consuming activity[1] and that moving the list
> service to a new host must be done by hand.
> 
> 
> Now, it's relatively easy for me to write a Perl script that uses the
> database interface and introspection capabilities to take a schema
> description and converge the existing SQL tables with that.
> 
> I could, therefore, write this script and use cfengine to transfer it
> and the schema to the host, then run it routinely to ensure that the
> database converged correctly.
> 
> 
> This seems a bit odd, though. I manage other data with cfengine
> directly, using the high level policy language and would like to have my
> database schema management integrated directly with that, not as some
> sort of second class citizen.
> 
> 
> I have read the documentation on cfengine modules and, to me, it looks
> like they do half of the job I want. I could easily schedule the Perl
> script to run and converge the schema with the desired layout.
> 
> It still seemed like I would need the schema description to be stored in
> another file, though -- I couldn't give it the same status as the
> 'files' or 'tidy' action.
> 
> 
> It seems, in fact, that the cfengine modules are intended to be either a
> way of conveniently extracting more information from system databases
> (installed packages, etc) or for performing a single specific task.
> 
> 
> If I have missed some detail in the documentation, or if the
> documentation is incomplete, I would love to know that I can extend
> cfengine at a high level.
> 
> Alternately, am I looking at the problem the wrong way? Is this, in
> fact, something that I should write a special purpose script for, not
> something that I should be trying to add as a generic feature to
> cfengine?
> 
> Regards,
>         Daniel Pittman
> 
> Footnotes: 
> [1]  For relatively small values of time consuming, but enough to be an
>      annoyance, especially if certain other, more mutable, SQL data
>      storage ends up being required.
> 
> -- 
> Men become civilized, not in proportion to their willingness to believe, but
> in proportion to their readiness to doubt.
>         -- H. L. Mencken
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine



--
Frank Smith                                                fsmith@hoovers.com
Systems Administrator                                     Voice: 512-374-4673
Hoover's Online                                             Fax: 512-374-4501