help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cfengine-1.6.2 copy doesn't replicate symlinks properly?


From: Mark . Burgess
Subject: Re: cfengine-1.6.2 copy doesn't replicate symlinks properly?
Date: Sat, 3 Mar 2001 22:44:35 +0100 (MET)

Thansk for your feedback on the manual. Writing manuals is hard and dull
work! I know it has many faults, but this kind of feedback helps.


best Mark

On  3 Mar, J. Maynard Gelinas wrote:
>   Hi Mark,
> 
>   Thanks for the tip. I'm sorry I haven't replied sooner, I've just been 
> busy. 
> So it looks like setting typecheck=false in my script will resolve my problem 
> with symbolic links.  Good.
> 
>    But I want to make the point that there's no way I would have correlated 
> what the reference manual says about the typecheck directive, and the effect 
> I 
> desired from cfengine. I had looked at typecheck carefully and concluded that 
> it limits only the output of error messages from cfengine, not what *action* 
> cfengine might take.
> 
>    In the copy action similar problems of ambiguity within the cfengine 
> reference include the "ignore" directive, the "include" directive and the 
> "exclude" directive. From testing I've determined that the difference between 
> "ignore" and "exclude" is that:
> 
> Ignore
> 
>    a) ignore can take a comma separated list of directories similar to a 
> $PATH 
> variable.
>    b) ignore won't purge files on a client down an ignored path, unlike 
> "exclude", if purge is set to "true"
>    c) ignore can be set globally using the global ignore directive, which 
> passes a list of ignored directories to every action listed in the action 
> sequence, or defined on the command line.
> 
> Exclude: 
> 
>    a) Exclude takes only "patterns", not paths. One cannot give a list of 
> absolute paths to individual files or directories which won't be copied, only 
> patterns which represent files or directories. For example:
> 
>  exclude = hosts passwd shadow group lilo.conf 
> 
> works, while:
> 
>  exclude = /etc/hosts:/etc/passwd:/etc/shadow:/etc/group:/etc/lilo.conf
> 
> Will NOT work. 
> 
>     b) Exclude and include don't affect purge operations, which could cause 
> serious data loss with a misconfigured cfengine.conf.
>   
>     b) Exclude can be configured globally by defining ExcludeCopy variable 
> within the control: section and providing a list of *patters* to exclude from 
> copying.
> 
>    On the difference between exclude and ignore, the reference manual states 
> "... Unlike include, exclude this affects the way cfengine parses directory 
> trees". And for exclude the manual states "This option may be repeated a 
> number of times to specify the names of files or wildcards which match files 
> which are to be excluded from a copy operation." I can find no examples of 
> exclude and include in the sample scripts provided, however based on this one 
> would assume that exclude (or it's global variable) should be able to take 
> complete paths to files one wishes to exclude. One might also conclude that 
> within a copy operation one can list multiple exclude directives.
> 
>   copy:
> 
>  /path/to/template/tree 
>  dest=/path/to/client/tree
>  ignore=/tmp
>  exclude=/etc/hosts
>  exclude=/etc/passwd
>  exclude=/etc/shadow
>  exclude=/etc/lilo.conf
>  recurse=inf
>  type=ctime
>  purge=true
>  server=cfd.internal.org
>  
>  (and I guess)
> 
>  typecheck=false
> 
> 
>   These multiple exclude directives will be ignored (based upon my tests) 
> within cfengine-1.6.2, but the only way I could have determined this would be 
> by running tests and watching -d1 and -d2 debug output to determine how 
> cfengine parsed the config file, and then watching what it does. The 
> difference between how ignore and exclude are parsed by cfengine, and the 
> fact 
> that one is globally configured by a directive, while the other by setting a 
> variable within control: also lead to confusion. None of this appears 
> explicitly stated either in the reference manual, or the tutorial.
> 
>    I want to make clear that I'm *NOT* writing this to personally insult or
> criticize the core developers and documentation authors of the cfengine
> project, but I *DO* think you need feedback about the ambiguities within the
> cfengine reference manual. I repeat: there's simply no way I would have
> concluded that suppressing error output should or would affect the success of 
> a
> copy operation.  In the same way that I couldn't have determined the
> differences between the exclude and ignore directives without directly testing
> them myself and watching the debug output combined with the results of a copy
> operation. 
> 
>     cfeninge is still a wonderfully useful tool which I'm glad I discovered. 
> I 
> thank you for the valuable tool, and your helpful reply.
> 
> Cheers,
> --Maynard
> 
>> Mark Burgess Wrote:
> 
>> On 27 Feb, J. Maynard Gelinas wrote:
> 
>> > 
>> >    I've got the copy operation working properly, and it appears to
>> > work for the most part. However, I've noticed what appears to be a
>> > serious problem in it's handling of Symbolic links: if a client has
>> > a symlink down the directory path, but the server has replaced that
>> > link with a file, the copy operation will fail and leave the original
>> > link in place on the client. It also appears that if a file is in
>> > place on the client, but a symbolic link with that filename is on
>> > the server, the client cfengine won't replace the file with the 
>> > proper link. 
>> > 
> 
>> From the manual:
>> 
>> typecheck=false (default is true)
>> 
>> Switches on/off error messages if source and existing
>> destination files do not match in type, e.g. if a file would overwrite a
>> directory or link. 
>> 
> 
> 

-- 


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]