Re: Determine file to copy based on classes

[Wipf, Stefan]

When we first started using cfengine we thought of doing this
sort of thing and I think many cfengine users actually are, but
on second thought we realized that as the environment grows
this really becomes a very bad idea:

- should files disappear from your file structure for whatever reason
the consequences are not immediately obvious.  Cfengine would quietly
copy in files that you didn't expect it to.

- The entire scheme can easily become messy and confusing.  As you will
likely be using your classes for more than one action, you will get to
the point where you won't be able to easily tell which class is the most
specific.

- Cfengine config files are a more reliable source upon which to take
action than a filestructure.

- most infrastructures can't be broken down into a simple tree like
this anyway.  Some specific class might want to get some files from a
subclass of a completely different branch.

I admit, the following examples are more work on the config file side,
but they are easier to decipher, safer and scale better than a
filestructure based scheme.  If a file goes missing on the source side,
cfengine will complain about it and do nothing, which is way better
than quietly doing something completely unexpected.
 

groups:
  uniq_motd = ( class_A class_B )

copy:
  class_A::
     somedir/motd.classA   dest=/etc/motd
  class_B::
     somedir/motd.classB   dest=/etc/motd
  !uniq_motd::
     somedir/motd.default  dest=/etc/motd


or


control:
  class_A::            mysuffix = ( "classA" )
  class_B::            mysuffix = ( "classB" )
  !(class_A|class_B):: mysuffix = ( "default" )

copy:
  somedir/motd.${mysuffix} dest=/etc/motd




Kai Großjohann wrote:
> 
> Mark.Burgess@iu.hio.no writes:
> 
> > The cfengine way of doing this is to put the hosts and their
> > resources in the same class container. Then it happens automatically
> 
> Hm?
> 
> I don't grok this answer.  I wanted to have a directory (tree?) with
> files, and adding a file with the right name should make the right
> copying happen: derive the class from the name, then copy.
> 
> I could specify to recursively copy some repository tree.  I'd have
> one tree per class.  Then I'd make a rule for each tree/class.  I'd
> put the most general rule first and the most specific rule last, so
> that the most specific file wins.
> 
> The problem with this approach is that it always copies files, even
> if there is no change: if a specific file is to be used on a certain
> host, then the first rule to fire is the most general, which
> determines that the file is different, so copies it.  Then comes the
> more specific rule, which finds the file from the general rule, and
> copies it again.
> 
> Hm.  Given classes a, b, c, with a being most general and c being
> most specific, I could craft copying rules like so:
> 
> copy:
>     a.!b.!c::
>         ...copy directory a here...
> 
>     !a.b.!c::
>         ...copy directory b here...
> 
>     !a.!b.c::
>         ...copy directory c here...
> 
> That would work, after a fashion.  But it's a bear to maintain: I
> currently have 15 classes (for just about a dozen hosts), so adding a
> 16th class requires me to frob 15 "::" lines, making sure that there
> is no mistake, and also to add the 16th line.
> 
> And what happens if a host belongs to classes a and b?
> 
> Nonono, that won't work.
> 
> Did the above make it clearer what I mean?
> 
> PS: What is a "class container"?  I searched for "container" in the
>     CFengine reference and the tutorial, and found one match in the
>     "ACL" node.  The match didn't appear to be relevant.
> --
> Ambibibentists unite!
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine

-- 
Stefan Wipf
swipf@htc.com