copy locking problem up to 2.1.1, patch included

[Eric Sorenson]

Hi, attached is a naive patch to lock.c against 2.1.1. It fixes
a problem I discovered using 'singlecopy' to do most-specific
file copies from a repository as illustrated below. 

## BEGIN snippet
control:
    singlecopy = ( on )
    AllowRedefinitionOf = ( role )
    AddInstallable = ( dmz )

    dr = ( /export/home/local/cfengine2 )
    fs = ( sinistar.domain.com )

    any:: role = ( default )
    dmz:: role = ( dmz )

groups:
    # the following are various hostnames of machines in the DMZ
    dmz = ( nft nmx ns1 )

copy:
    $(dr)/etc/mail/sendmail.cf.$(host) server=$(fs) dest=/etc/mail/sendmail.cf 
mode=444
        owner=root group=root backup=false type=sum
    $(dr)/etc/mail/sendmail.cf.$(role) server=$(fs) dest=/etc/mail/sendmail.cf 
mode=444
        owner=root group=root backup=false type=sum
## END snippet

The idea is that in the repository there are several sendmail.cf, as
in:
    sendmail.cf.default
    sendmail.cf.dmz
    sendmail.cf.nmx

This means that 'nmx' will get its own special sendmail.cf, the
rest of the machines in the DMZ will get sendmail.cf.dmz, and
everyone else gets sendmail.cf.default.

The problem arises when there isn't a 'sendmail.cf.$(host)' for 
a given client's value of $(host). The output of 'cfagent -v' on host
'joust' (which ought to get sendmail.cf.default) shows:

Checking copy from 
sinistar:/export/home/local/cfengine2/dist/etc/mail/sendmail.cf.joust to 
/etc/mail/sendmail.cf
cfengine:joust: Server returned error:  Host authentication failed. Did you 
forget the domain name or IP/DNS address registration (for ipv4 or ipv6)?
cfengine:joust: Can't stat 
/export/home/local/cfengine2/dist/etc/mail/sendmail.cf.joust in copy
Checking copy from 
sinistar:/export/home/local/cfengine2/dist/etc/mail/sendmail.cf.default to 
/etc/mail/sendmail.cf
cfengine:joust: Nothing scheduled for 
copy._export_home_local_cfengine2_dist_etc_mail_sendmai__etc_mail_sendmail_cf 
(0/1 minutes elapsed)

It doesn't copy sendmail.cf.default because there's a lock in place
for that target file, even though the source file is different. If
the name of the lock was longer, I suppose it would succeed; but from
do.c:2470 we see

    snprintf(VBUFF,bufsize,"%.50s.%.50s",path,destination); /* Unique ID for 
copy locking */

The full path to the source file exeeds 50 characters before it diverges,
so the lock that is checked for sendmail.cf.joust doesn't differ from the
lock grabbed for sendmail.cf.default. A second later when that copy is 
supposed to happen the lock is still active ("0/1 minutes elapsed") so
it's gets skipped. I'm not sure what's going on in the 
ReleaseCurrentLock() calls, but running 'cfagent -K' doesn't exhibit
the behavior.

One fix might be to increase the path length of the lockfile name, but
I don't think my paths to the repository and files therein are really
excessive or out of the ordinary, and this still leaves a hidden 
landmine for the future.

What the attached patch does instead, then, is move the 'if(cfstat...)'
stanza at do.c:2481-2489 up above do.c:2470. If the cfstat doesn't
suceed, the copy isn't going to happen so it doesn't seem necessary
to grab a lock.  Again, this is somewhat naive, but it does work.

-- 

    Eric Sorenson - EXPLOSIVE Networking - http://explosive.net

cfengine-copylock.patch
Description: Text document