Re: DDD debug result -- RE: Please help! -- 2.1.11 cfengine delete /tmp symboliclinkmisteriously

[Mark . Burgess]

Thank you for this patch, I shall look into it as soon as I get time,

best wishes
Mark


On 22 Nov, Guolin Cheng wrote:
> Mark and Sven,
> 
>   I tried to debug the cfengine codes, and seems that there is a bug in the 
> following code, #495
>   line in function RecursiveTidySpecialArea in file tody.c:
> 
>     ....
> 
>     495    chdir("/");  /* Problem! */
>     496 
>     497    if (ok)
>     498       {
>     499       
> TidyParticularFile(name,ReadLastNode(name),tp,&topstatbuf,true,tp-       
>     >maxrecurse,true); 500       }
>     501    }
>     502 
>     503 return true;
>     504 }
>     505
>     ....
> 
>  The first BIG problem is, if the "name" variable above is only one layer 
> under root "/", then
>  above logic is correct by accident; if the "name" is unfortunately two or 
> three layers deep, like
>  "/var/tmp", then the logic is totally wrong. It should run 'chdir("/var")' 
> to unlink "tmp" for
>  the effect of unlinking "/var/tmp" correctly, otherwise it will unlink 
> totally unrelated "/tmp"!
> 
> Second problem (maybe suggestion better called) is: by default and 
> intuitively, cfengine should
> not travel upper-ward toward root "/"?  For my example,  all files and 
> subdirs under "/var/tmp"
> should be processed for possible tidy operation, but "/var/tmp/" ITSELF ( 
> whether /var/tmp/ is a
> link or directory)  and upper directories ( "/var", "/") should not be 
> searched.  Cfengine 2.1.11
> has a "sub" value for attribute "rmdir" to achieve this effect, but it seems 
> better to set this
> effect as the default, and set "upper" to achieve counter-effect.
> 
> Please ignore the second problem if it makes no sense to you. I talk about it 
> just because the
> current default behavior is a little, if not too much, counter-intuitive.
> 
> I've rolled a "quick and dirty patch" for problem #1 and tested it, it works 
> great for my case.
> Please have a look of it:
> 
> [root@cfengineTest src]# cat /usr/src/redhat/SOURCES/cfengine-tidy.patch 
> *** ./src/tidy.c_orig   2004-09-20 06:47:32.000000000 -0700
> --- ./src/tidy.c        2004-11-22 17:06:11.000000000 -0800
> ***************
> *** 324,329 ****
> --- 324,330 ----
>     DIR *dirh;
>     struct dirent *dirp;
>     char pcwd[CF_BUFSIZE];
> +   char *parentdir; 
>     int is_dir,level,goback;
>     
>   Debug("RecursiveTidySpecialArea(%s)\n",name);
> ***************
> *** 492,502 ****
>            }
>         }
>      
> -    chdir("/");
>   
>      if (ok)
>         {
> !       
> TidyParticularFile(name,ReadLastNode(name),tp,&topstatbuf,true,tp->maxrecurse,true);
>         }
>      }
>   
> --- 493,519 ----
>            }
>         }
>      
>   
>      if (ok)
>         {
> !       char* basename=ReadLastNode(name); /* the last node of a pathname 
> string  */
> !       if ( strlen(name) == strlen(basename) ) /* if name is something like 
> "tmp" */
> !               {
> !               chdir("/");
> !       }
> !       else /* if the names are like "/tmp", or "/var/tmp" */
> !       {
> !               if ( (parentdir = (char *)malloc(strlen(name)+1)) == NULL )
> !               {
> !                       FatalError("memory failure");
> !               }
> !               strcpy(parentdir, name); 
> !               *(parentdir+strlen(name)-strlen(basename)) = '\0'; 
> !               //printf("parentdir is %s\n", parentdir);  /* my ddd can not 
> show parentdir
> variable, strange */
> !               chdir(parentdir); /* now it can chdir to "/var". */
> !               free(parentdir);
> !       }
> !               
> TidyParticularFile(name,basename,tp,&topstatbuf,true,tp->maxrecurse,true);
>         }
>      }
>   
> [root@cfengineTest src]#
> 
> 
>  
> --Guolin
> 
> 
> 
> 
>   
> 
>  
> 
> 
> 
> 
> -----Original Message-----
> From: Guolin Cheng 
> Sent: Friday, November 12, 2004 12:32 PM
> To: Guolin Cheng; Sven Mueller; help-cfengine@gnu.org
> Cc: bug-cfengine@gnu.org
> Subject: RE: Please help! -- 2.1.11 cfengine delete /tmp 
> symboliclinkmisteriously
> 
> Mark and Sven,
> 
>  The problem is quite repeatable. It happens on all of my 6 test machines.
> 
>  If you setup the tidy operation like my first email, you definitely can see 
> the same thing
>  happens again and again.
> 
>  The confusion is mostly related to part to check "topmost directory" which 
> should not happen, and
>  even worse, delete unrelated /tmp. "WildMatch(*,tmp)" ???
> 
> 
>>>Checking tidy topmost directory /var/tmp
>>>Checking for dead links
>>>KillOldLink(/var/tmp)
>>>WildMatch(*,tmp)
>>>FileObjectFilter(/var/tmp)
>>>Applying filter tmpSpaceTidy
>>>Filter result on /var/tmp was 1
>>>IgnoredOrExcluded(/var/tmp)
>>>Link to directory, dirlinks= says delete these
>>>cfengine:alws10: Deleting file /var/tmp
>>>cfengine:alws10: Size=15 bytes,
> 
> 
>  --Guolin
> 
>  
> 
> -----Original Message-----
> From: help-cfengine-bounces+guolin=alexa.com@gnu.org
> [mailto:help-cfengine-bounces+guolin=alexa.com@gnu.org] On Behalf Of Guolin 
> Cheng Sent: Friday,
> November 12, 2004 12:25 PM To: Sven Mueller; help-cfengine@gnu.org
> Cc: bug-cfengine@gnu.org
> Subject: RE: Please help! -- 2.1.11 cfengine delete /tmp 
> symboliclinkmisteriously
> 
> Mark and Sven,
> 
>  Sven is right, I do mean that: /var/tmp/ should not be touched at all. Only 
> files,
>  subDirectories, symbolic links and sockets UNDER /var/tmp/ will be handled.
> 
> Unfortunately, according to the debug output, /var/tmp/ and /tmp (I don't 
> know why unrelated /tmp
> is processes by cfengine ??) are also processed for tidy operation, maybe 
> also "/var/*" and "/*"?
> this is a little counter-intuitive since cfengine here is "upwards" as well 
> instead ONLY
> "downwards" to only its file|subDir|links|sockets contents. Cfengine should 
> process, by default
> intuitively, only contents UNDER the specified directory.
> 
> Maybe I'm wrong, or misunderstand tidy operation. Please help.
> 
> --Guolin Cheng
>  
> 
> 
> 
> Mark.Burgess@iu.hio.no [u] wrote on 12/11/2004 06:07:
> 
> That seems to be only partly true. He did ask cfagent to clear directory 
> links, but only for /var/tmp, but /tmp got deleted, while /var/tmp 
> remained intact. At least if I read his mail correctly.
> 
> cu,
> Sven
> 
>> You have explicitly asked for dirlinks=tidy, so this is
>> correct. There was a bug here earlier.
>> 
>> M
>> 
>> On 11 Nov, ha haha wrote:
>> 
>>>Hi,
>>>
>>>  Yesterday I've updated my cfengine from 2.1.7p1 to
>>>2.1.11. The new packages compiled and installed
>>>successfully. But unfortunately, it mis-interpret my
>>>configuration files which worked for 2.1.7p1 with no
>>>faults. And deleted my /tmp symbolic link by mistake.
>>>
>>>  The background information is:
>>>
>>>     1),     I have two links /tmp -> ../0/.final/tmp, 
>>>/var/tmp -> ../0/.final/tmp, while /0/.final/tmp is a
>>>directory.
>>>
>>>      2),   /var, /, and /0 are three dfferent
>>>partitions.
>>>
>>>      3),   my "tidy" related sections for the
>>>/var/tmp/ is:
>>>
>>>¡­¡­¡­¡­¡­..
>>>control:
>>>
>>>   actionsequence = ( directories files links tidy
>>>disable copy editfiles processes shellcommands 
>>>¡­¡­¡­..)
>>>
>>>tidy:
>>>    any::
>>>
>>>        /var/tmp/
>>>            pattern=*
>>>            filter=tmpSpaceTidy
>>>            recurse=inf
>>>            type=mtime
>>>            rmdirs=true
>>>            links=tidy
>>>            dirlinks=tidy
>>>            age=39
>>>            inform=true
>>>
>>>¡­¡­¡­.
>>>filters:
>>>
>>>   { tmpSpaceTidy
>>>          Type: "reg|dir|link|socket"
>>>          Result: "Type"
>>>   }
>>>¡­¡­¡­¡­¡­..
>>>
>>> After I run "cfagent  -v -q", then I got the
>>>following line (15 bytes is the total bytes of
>>>symbolic link destination "../0/.final/tmp":
>>>
>>>*********************************************************************
>>> Main Tree Sched: tidy pass 1 @ Thu Nov 11 18:18:53
>>>2004
>>>*********************************************************************
>>>¡­¡­¡­..
>>>---------------------------------------------------------------------
>>>Tidying by directory
>>>---------------------------------------------------------------------
>>>
>>>cfengine:alws10: Deleting file /var/tmp
>>>cfengine:alws10: Size=15 bytes,
>>>             
>>>             ¡­¡­
>>>
>>>It is very strange, since not symbolic link "var/tmp"
>>>is deleted, but /tmp llink which points to same
>>>destination!
>>>
>>>Then I tried to output the debug desult with "cfagent
>>>-v -d10 -q", and got the following output:
>>>
>>>            ¡­¡­¡­¡­¡­¡­..
>>>
>>>---------------------------------------------------------------------
>>>Tidying by directory
>>>---------------------------------------------------------------------
>>>
>>>
>>>No patterns active in base directory
>>>/var/lib/cfengine2/outputs
>>>
>>>Tidying from base directory /var/tmp
>>>ExpandVarstring(/var/tmp)
>>>ExpandVarstring(/tmp)
>>>GetLock(tidy,_var_tmp,time=1100226190),
>>>ExpireAfter=120, IfElapsed=1
>>>GetLastLock()
>>>CheckOldLock(lock.cfagent_conf.alws10.tidy.tidy_1298)
>>>Unable to find lock data
>>>lock.cfagent_conf.alws10.tidy.tidy_1298
>>>SetLock(lock.cfagent_conf.alws10.tidy.tidy_1298)
>>>PutLock(lock.cfagent_conf.alws10.tidy.tidy_1298)
>>>Found no lock
>>>[lock.cfagent_conf.alws10.tidy.tidy_1298]:
>>>DB_NOTFOUND: No matching key/data pair found
>>>Registering root device as 2059
>>>RecursiveTidySpecialArea(/var/tmp)
>>>Changed directory to /var/tmp
>>>Checking the inode and device to make sure we are
>>>where we think we are...
>>>IgnoredOrExcluded(/var/tmp)
>>>IgnoreFile(/var/tmp,)
>>>Tidy: opening dir /var/tmp
>>>Filename /var/tmp/. is classified as ignorable
>>>Filename /var/tmp/.. is classified as ignorable
>>>IgnoreFile(/var/tmp,cfengine-2.1.11-1.i386.rpm)
>>>WildMatch(*,cfengine-2.1.11-1.i386.rpm)
>>>FileObjectFilter(/var/tmp/cfengine-2.1.11-1.i386.rpm)
>>>Applying filter tmpSpaceTidy
>>>Filter result on /var/tmp/cfengine-2.1.11-1.i386.rpm
>>>was 1
>>>IgnoredOrExcluded(/var/tmp/cfengine-2.1.11-1.i386.rpm)
>>>Checking tidy topmost directory /var/tmp
>>>Checking for dead links
>>>KillOldLink(/var/tmp)
>>>WildMatch(*,tmp)
>>>FileObjectFilter(/var/tmp)
>>>Applying filter tmpSpaceTidy
>>>Filter result on /var/tmp was 1
>>>IgnoredOrExcluded(/var/tmp)
>>>Link to directory, dirlinks= says delete these
>>>cfengine:alws10: Deleting file /var/tmp
>>>cfengine:alws10: Size=15 bytes,
>>>ReleaseCurrentLock(lock.cfagent_conf.alws10.tidy.tidy_1298)
>>>PutLock(last.cfagent_conf.alws10.tidy.tidy_1298)
>>>LockLog(Lock removed normally )
>>>
>>>     ¡­¡­¡­¡­¡­
>>>
>>>
>>>I have no otherchoise, but have to temporarily fix the
>>>problem by the following changes:
>>>
>>>    rmdir=sub   ## original is "true"
>>>    xdev=false  ## orignally doesn't exist
>>>    
>>>It is only a temporary fix for the above problem.
>>>Please help.
>>> 
>>> 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>             
>>>__________________________________ 
>>>Do you Yahoo!? 
>>>Check out the new Yahoo! Front Page. 
>>>www.yahoo.com 
>>> 
>> 
>> 
>> 
>> 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
>> Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> 
>> 
>> _______________________________________________
>> Help-cfengine mailing list
>> Help-cfengine@gnu.org
>> http://lists.gnu.org/mailman/listinfo/help-cfengine
>> 
>> 
> 
> 



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~