[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Template resource: default value for mode attribute?

[Daniel DeLeo < >]

On Wednesday, June 15, 2011 at 8:43 AM, Brian Akins wrote:

> 
> 
> On Wed, Jun 15, 2011 at 10:38 AM, Allan Wind 
> <
 
>  
> (mailto:
 )>
>  wrote:
> > 
> > $ strace cp 1 2
> >  ...
> >  open("1", O_RDONLY) = 3
> >  fstat(3, {st_mode=S_IFREG|0644, st_size=1048576, ...}) = 0
> >  open("2", O_WRONLY|O_TRUNC) = 4
> 
> Confirmed that FileUtils.cp does the same. Probably not a good thing. 
The original behavior of these providers was to use FileUtils.cp, and this is 
why it was changed. That said, mv is only atomic for moves on the same 
partition. We had a discussion about this on the dev list a few weeks back in 
the context of Windows ACLs, which are similarly mangled when using mv.

My favored solution is to create a temporary file right next to the target 
file, so if you were writing /etc/chef/client.rb from a template, you would 
use /etc/chef/client.rb.RANDOM_SLUG as the temporary file. Of course, in the 
case that something has registered to watch this directory, you could get 
misbehavior, and extreme failure cases, such as segfaults in the ruby runtime 
could leave these files in that directory, which would be problematic for 
multi-file (e.g., conf.d and friends) configurations. It also does not solve 
the permissions issue raised here, but that can be fixed by patching the 
providers to set the desired file mode to the current one when not explicitly 
specified; there is nothing that can be done to make cp atomic.

I should also mention that I'm a bit uncomfortable with the outcome of 
converging a resource being dependent on initial system state outside of the 
resource, but then again, I would not go so far as to make file modes 
required for file resources. Suggestions or thoughts about this would be 
welcome.

-- 
Dan DeLeo