help-cfengine
[Top][All Lists]
Advanced

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

Re: syntax reference


From: Chris Edillon
Subject: Re: syntax reference
Date: Fri, 14 Sep 2001 22:34:20 -0400 (GMT+4)

On 14 Sep 2001, Roy Marantz wrote:

> Does anyone know of a detailed description of the syntax of cfengine,
> say in some kind of BNF or somthing?  I'm using (with varying degrees
> of success) version 1.6.3.  In particular I keeping running into
> problems with macros/variables such as how to define them (in a groups
> part and/or module) and where they get expanded.  I'd love there to be
> a way to include the contents of a variable in a REGEX, but I don't
> see one.  I'm trying to avoid pouring over the source, so any help
> would be appreciated.  Thanks in advance.
> 
  don't know of any grammar description; mark would be the one to
as about that i guess.  however, i can try to answer your questions
on macros.

  macros or variables are defined under the control: section of a
cfengine script using the following syntax:

    variable = ( value )

in general, whitespace should be used around the open and close
parentheses so that the parser doesn't get confused (per the
documentation, and i've seen problems when it isn't used).  for
values containing whitespace, the value can be quoted:

    variable = ( "has whitespace" )

values can also come from the output of an arbitrary executable:

    variable = ( "exec /bin/domainname" )

the full path to the executable must be used, or else cfengine
considers the quoted string to be exactly that: a string.  given
the following:

    host = ( "exec hostname" )

the variable $(host) contains the value "exec hostname" and not
the machine's hostname.  executing a single binary/script is the
norm; as adrian phillips mentions in a previous post, piplining
can be done but you have to use a few tricks.

  note that defining a variable looks very similar to defining
a new class, which can be confusing at first.  classes are all
defined under a classes: or groups: section, whereas variables
or macros are defined only under a control: section.

  once you've defined a variable, you reference it with the form
$(variable) or ${variable}.  the parentheses or braces are
mandatory.  as far as i can determine from testing, you can use
a variable anywhere in a cfengine script, as i believe that
variable substitution is done during or just after parsing, and
before any actions are taken.  for a definitive answer, though,
you'd have to check the source (or ask mark).

  so, you can in fact use a variable in a regex.  the following
works just fine for me:

    control:
        actionsequence = ( editfiles )
        var1 = ( foo )

    editfiles:
        any::
            { /tmp/testfile
              DeleteLinesMatching "^$(var1).*"
            }

it acts as expected and deletes any lines beginning with "foo"
in /tmp/testfile.  you can even do things like this:

    control:
        actionsequence = ( editfiles )
        passwd = ( /etc/passwd )

    editfiles:
        any::
            { $(passwd)
              DeleteLinesMatching "^fred:.*"
            }

this comes in handy when you work in a heterogenous environment
in which different operating systems have different names/paths
for the same files.  for example, on solaris /etc/vfstab is in
general the same as /etc/fstab everywhere else.  so instead of
doing two separate editfiles rules to add something to these
files:

    editfiles:
        solaris::
            { /etc/vfstab
              # do some complicated edit
            }

        !solaris::
            { /etc/fstab
              # do same edit
            }

you could make your edit rule more generic and your script less
messy using a variable:

    control:
       solaris::    fstab = ( /etc/vfstab )
       !solaris::   fstab = ( /etc/fstab )

    editfiles:
        any::
            { $(fstab)
              # do some complicated edit
            }

granted, this is a contrived example, but i use this at work
all the time for enumerating init script locations (/etc/init.d
on most unix systems, /sbin/init.d on OSF1 or HP-UX,
/etc/rc.d/init.d on redhat or mandrake, etc.), doing the same
edit on files with different names/paths according to OS, or
what have you.  since the environment i work in consists of

  ok, so that was a bit long-winded, but i hope it helps you out
in some way.  :-)

chris




reply via email to

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