Single-copy source selection bug...

[Jay 'Whip' Grizzard]

Alright, so I've had some weirdness with singlecopy recently, and I 
think I've figured out what's going on. I think this behavior is a bug,
so here's a report. I tried to post this a bit ago (per the README), but 
apparently the bug-cfengine mailing list won't allow you to submit a bug 
report without first being a subscriber to the list! Someone might 
consider changing that behavior, since requiring mailing list membership
just to file a bug report seems an ineffective way to actually get them.



Anyhow, the docs for singlecopy say:

: If a singlecopy pattern is defined the behavior of copy: is modified so 
: that a given destination file, matching the pattern, will only be 
: updated once.

This still seems to be technically true, for the behavior I'm seeing, but
not in a particularly useful way. Let me see if I can explain what's going
on well enough that someone could reproduce the bug.

I'll use my 'sudoers' file as an example. I want to use singlecopy so that
I can have different sudoers files in different environments, and one 
'generic' sudoers file that's used if a more specific one isn't specified.
This seems to be the intent of the singlecopy feature, so all's good so
far. 

I have the following set up in my main 'control' section:

    singlecopy      = ( on )
    DefaultCopyType = ( checksum )



And I have the following set up in one of my 'copy' sections:

    ${dr}/${role}/sudoers server=${fs} dest=/opt/csw/etc/sudoers owner=root 
group=root mode=0440
    ${dr}/general/sudoers server=${fs} dest=/opt/csw/etc/sudoers owner=root 
group=root mode=0440


What I -expect- to happen is that it would check ${role}/sudoers, and if
it existed, it would process that rule and never even consider the second
(general) rule.

What seems to actually be happening, though, is that it's checking to
see if ${role}/sudoers needs updating (e.g. what's on the client system
differs from what's in the repository). When it doesn't need updating 
(because it's up to date), it then considers the second (general) rule, 
finds that the file is out of date, and updates it from the general 
repository (which is the wrong file).

Relevent output from a cfagent --verbose run, one a few minutes after the
other, showing how it swaps back and forth between the two possible files.
This is with role=qa ...


Initial execution (pulls from dist/qa/sudoers):

    Checking copy from 
configs.domain.com:/var/cfengine/masterfiles/dist/qa/sudoers to 
/opt/csw/etc/sudoers
    cfengine:qa-client: Update of image /opt/csw/etc/sudoers from master 
/var/cfengine/masterfiles/dist/qa/sudoers on configs.domain.com
    Checking copy from 
configs.domain.com:/var/cfengine/masterfiles/dist/general/sudoers to 
/opt/csw/etc/sudoers



A few minutes later (pulls from dist/general/sudoers):

    Checking copy from 
configs.domain.com:/var/cfengine/masterfiles/dist/qa/sudoers to 
/opt/csw/etc/sudoers
    Checking copy from 
configs.domain.com:/var/cfengine/masterfiles/dist/general/sudoers to 
/opt/csw/etc/sudoers
    cfengine:qa-client: Update of image /opt/csw/etc/sudoers from master 
/var/cfengine/masterfiles/dist/general/sudoers on configs.domain.com



This is with cfengine 2.1.19p1 on sparc Solaris 9.

I appreciate feedback, fixes, and ideas for a quick-to-implement workaround
that will get my coworkers to stop screaming at me about "this stupid new
config system." 

Thanks!

-jay

----- End forwarded message -----