copy locking problem up to 2.1.1, patch included (fwd)

[Eric Sorenson]

I posted this to the bug-cfengine list earlier today but
it still hasn't show up, maybe my subscription isn't approved
or something (I just signed up yesterday :) )

Anyway, near as I can tell this describes the root cause of the
problem Pete mentioned earlier. You can tell it is the same 
because the error messages are just as I describe and the
lock name is truncated at 50 characters for each of the source
and destination file -- look for the "__" string in the lockname;
if the pathname leading up to it is incomplete, and the 
pathelements which differentiate it from a previous copy are
below the truncation point, guess what? It's not a "Unique ID".

-- 

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

---------- Forwarded message ----------
Date: Tue, 20 Jan 2004 10:16:55 -0800 (PST)
From: Eric Sorenson <eric@explosive.net>
To: bug-cfengine@gnu.org
Subject: copy locking problem up to 2.1.1, patch included


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