[Top][All Lists]

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

Re: Support for XML config files?

From: Christopher Browne
Subject: Re: Support for XML config files?
Date: Thu, 15 Mar 2001 21:08:39 -0600

On Thu, 15 Mar 2001 14:32:54 PST, the world broke into rejoicing as
Hal Wine <address@hidden>  said:
> However, more and more of the config files I need to manage are switching
> from "line format" to XML format. I don't see any reference to XML in the
> docs -- has anybody had success with this?

Hmmm...  If there are truly complex things going on, you may need to
write a parser in Python/Perl/Scheme, and have cfengine invoke that

> Also, some of our line based files are really "multi-line" (think
> printcap).  I'm sure that there is some magic incantations with
> CFEngine that can handle that, but are there any examples
> documented?

Take a close look at the "editfiles" section in the reference guide.

I'm afraid it doesn't document any terribly sophisticated examples, so
the straight answer to your question is "no."  

But there certainly are the "magic incantations" to handle it.

This is where things kind of fall down.  In effect, cfengine has to
add a "text editor" sublanguage for people to learn.

Thinking out loud, the "I've got to punt, and do Scary Things to a
file" thing suggests that it might be a slick idea to provide a
cfengine section rather like:

   file=/etc/printcap \
   arglist=( Postscript $hostname $printserver )

Which would then do the following:
 -> invoke the filter /etc/cfengine/FixPrintcap
   -> Pass to it the expanded arguments
   -> attach stdin to /etc/printcap
   -> attach stdout to /etc/printcap.cfnew
 -> Once done, look at the return codes
   -> Nonzero indicates that /etc/printcap.cfnew is renamed to
      /etc/printcap.proposed, and /etc/printcap is left alone
   -> Zero return code results in /etc/printcap being renamed to
      /etc/printcap.cfsaved, and /etc/printcap.cfnew renamed to

The point here is to provide a way of hooking up arbitrary filters in
a fashion that still allows ensuring that hideous failures lead to not
_too_ much breakage of configuration, and that backups of
configuration are done.  It is also arguable that a "diff -u" should
be run on the config files, and logged in an analagous fashion to the
way "editfiles:" works.
(concatenate 'string "cbbrowne" "")
Rules of the  Evil Overlord #22. "No matter how tempted  I am with the
prospect  of unlimited  power, I  will  not consume  any energy  field
bigger than my head. <>

reply via email to

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