# Template resource: default value for mode attribute?

**URL:** <https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887>\
**Category:** Chef Infra (archive)\
**Created:** [June 3, 2011, 2:34am UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887 "2011-06-03T02:34:21Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![Faiz\_Kazi](https://avatars.discourse-cdn.com/v4/letter/f/35a633/32.png) [@Faiz\_Kazi](https://discourse.chef.io/u/Faiz_Kazi)\
**Post date:** [June 3, 2011, 2:34am UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/1 "2011-06-03T02:34:21Z")

</div>

It appears that if one does not specify a mode,  
files generated/overwritten by template resources  
end up having permissions like -rw------- (0600).

This seems like a sane default. But maybe the  
documentation should make this explicit.  
Right now, the template resource wiki page  
[http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
reads:

Attribute: mode  
Description: "The octal mode of the file - 0755"  
Default Value: (nothing here)

Take for example the simple case of managing /etc/hosts.  
This file usually has permissions -rw-r–r--.

template '/etc/hosts’  
source 'hosts.erb’  
end

… will overwrite /etc/hosts as expected, but if one  
forgets to pass in the mode attribute, '/etc/hosts’  
ends up as readable only by root (i.e., -rw-------).

This is not really a major problem (I simply make sure  
to pass in a mode explicitly).  
but as a suggestion:

(1) For existing files that get ‘templated’,  
chef-client could just leave the permissions untouched.

OR

(2) Fix the docs to make it very clear that unless  
one specifies a mode explicitly, the file  
created/overwritten by the template will end up  
with the default mode (and that the default  
mode is 0600, not 0755)

For the record, I’m still running 0.9.16.

Thanks,  
Faiz

---

<div class="post-metadata">

**Author:** ![Matt\_Ray\_OPSCODE](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/matt_ray_opscode/32/459_2.png) [@Matt\_Ray\_OPSCODE](https://discourse.chef.io/u/Matt_Ray_OPSCODE)\
**Post date:** [June 3, 2011, 2:43pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/2 "2011-06-03T14:43:09Z")

</div>

I verified this and I've updated the Template entry on the Resources  
page to reflect the default.  
[http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)

Thanks,  
Matt Ray  
Senior Technical Evangelist | Opscode Inc.  
[matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
Twitter, IRC, GitHub: mattray

On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:

> It appears that if one does not specify a mode,  
> files generated/overwritten by template resources  
> end up having permissions like -rw------- (0600).
> 
> This seems like a sane default. But maybe the  
> documentation should make this explicit.  
> Right now, the template resource wiki page  
> [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> reads:
> 
> Attribute: mode  
> Description: "The octal mode of the file - 0755"  
> Default Value: (nothing here)
> 
> Take for example the simple case of managing /etc/hosts.  
> This file usually has permissions -rw-r--r--.
> 
> template '/etc/hosts'  
> source 'hosts.erb'  
> end
> 
> .. will overwrite /etc/hosts as expected, but if one  
> forgets to pass in the mode attribute, '/etc/hosts'  
> ends up as readable only by root (i.e., -rw-------).
> 
> This is not really a major problem (I simply make sure  
> to pass in a mode explicitly).  
> but as a suggestion:
> 
> (1) For existing files that get 'templated',  
> chef-client could just leave the permissions untouched.
> 
> OR
> 
> (2) Fix the docs to make it very clear that unless  
> one specifies a mode explicitly, the file  
> created/overwritten by the template will end up  
> with the default mode (and that the default  
> mode is 0600, not 0755)
> 
> For the record, I'm still running 0.9.16.
> 
> Thanks,  
> Faiz

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [June 3, 2011, 7:27pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/3 "2011-06-03T19:27:16Z")

</div>

This is not always the default - it's going to be a reflection of the  
user who runs chef's umask. Most operating systems will have this be  
0600, but not all of them will - so you can't rely on it as a general  
rule.

Adam

On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:

> I verified this and I've updated the Template entry on the Resources  
> page to reflect the default.  
> [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)
> 
> Thanks,  
> Matt Ray  
> Senior Technical Evangelist | Opscode Inc.  
> [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> Twitter, IRC, GitHub: mattray
> 
> On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:
> 
> > It appears that if one does not specify a mode,  
> > files generated/overwritten by template resources  
> > end up having permissions like -rw------- (0600).
> > 
> > This seems like a sane default. But maybe the  
> > documentation should make this explicit.  
> > Right now, the template resource wiki page  
> > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> > reads:
> > 
> > Attribute: mode  
> > Description: "The octal mode of the file - 0755"  
> > Default Value: (nothing here)
> > 
> > Take for example the simple case of managing /etc/hosts.  
> > This file usually has permissions -rw-r--r--.
> > 
> > template '/etc/hosts'  
> > source 'hosts.erb'  
> > end
> > 
> > .. will overwrite /etc/hosts as expected, but if one  
> > forgets to pass in the mode attribute, '/etc/hosts'  
> > ends up as readable only by root (i.e., -rw-------).
> > 
> > This is not really a major problem (I simply make sure  
> > to pass in a mode explicitly).  
> > but as a suggestion:
> > 
> > (1) For existing files that get 'templated',  
> > chef-client could just leave the permissions untouched.
> > 
> > OR
> > 
> > (2) Fix the docs to make it very clear that unless  
> > one specifies a mode explicitly, the file  
> > created/overwritten by the template will end up  
> > with the default mode (and that the default  
> > mode is 0600, not 0755)
> > 
> > For the record, I'm still running 0.9.16.
> > 
> > Thanks,  
> > Faiz

--  
Opscode, Inc.  
Adam Jacob, Chief Product Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![Matt\_Ray\_OPSCODE](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/matt_ray_opscode/32/459_2.png) [@Matt\_Ray\_OPSCODE](https://discourse.chef.io/u/Matt_Ray_OPSCODE)\
**Post date:** [June 3, 2011, 9:19pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/4 "2011-06-03T21:19:41Z")

</div>

Reverted my edit then. Does this behavior go for File, Template,  
Remote\_File and Cookbook\_File? If so should we note it in File  
Distribution page?  
[http://wiki.opscode.com/display/chef/File+Distribution#FileDistribution-FileSpecificity](http://wiki.opscode.com/display/chef/File+Distribution#FileDistribution-FileSpecificity)

Thanks,  
Matt Ray  
Senior Technical Evangelist | Opscode Inc.  
[matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
Twitter, IRC, GitHub: mattray

On Fri, Jun 3, 2011 at 2:27 PM, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

> This is not always the default - it's going to be a reflection of the  
> user who runs chef's umask. Most operating systems will have this be  
> 0600, but not all of them will - so you can't rely on it as a general  
> rule.
> 
> Adam
> 
> On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:
> 
> > I verified this and I've updated the Template entry on the Resources  
> > page to reflect the default.  
> > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)
> > 
> > Thanks,  
> > Matt Ray  
> > Senior Technical Evangelist | Opscode Inc.  
> > [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> > Twitter, IRC, GitHub: mattray
> > 
> > On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:
> > 
> > > It appears that if one does not specify a mode,  
> > > files generated/overwritten by template resources  
> > > end up having permissions like -rw------- (0600).
> > > 
> > > This seems like a sane default. But maybe the  
> > > documentation should make this explicit.  
> > > Right now, the template resource wiki page  
> > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> > > reads:
> > > 
> > > Attribute: mode  
> > > Description: "The octal mode of the file - 0755"  
> > > Default Value: (nothing here)
> > > 
> > > Take for example the simple case of managing /etc/hosts.  
> > > This file usually has permissions -rw-r--r--.
> > > 
> > > template '/etc/hosts'  
> > > source 'hosts.erb'  
> > > end
> > > 
> > > .. will overwrite /etc/hosts as expected, but if one  
> > > forgets to pass in the mode attribute, '/etc/hosts'  
> > > ends up as readable only by root (i.e., -rw-------).
> > > 
> > > This is not really a major problem (I simply make sure  
> > > to pass in a mode explicitly).  
> > > but as a suggestion:
> > > 
> > > (1) For existing files that get 'templated',  
> > > chef-client could just leave the permissions untouched.
> > > 
> > > OR
> > > 
> > > (2) Fix the docs to make it very clear that unless  
> > > one specifies a mode explicitly, the file  
> > > created/overwritten by the template will end up  
> > > with the default mode (and that the default  
> > > mode is 0600, not 0755)
> > > 
> > > For the record, I'm still running 0.9.16.
> > > 
> > > Thanks,  
> > > Faiz
> 
> --  
> Opscode, Inc.  
> Adam Jacob, Chief Product Officer  
> T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [June 3, 2011, 10:00pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/5 "2011-06-03T22:00:39Z")

</div>

It's true anything that writes a file.

Adam

On Fri, Jun 3, 2011 at 2:19 PM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:

> Reverted my edit then. Does this behavior go for File, Template,  
> Remote\_File and Cookbook\_File? If so should we note it in File  
> Distribution page?  
> [http://wiki.opscode.com/display/chef/File+Distribution#FileDistribution-FileSpecificity](http://wiki.opscode.com/display/chef/File+Distribution#FileDistribution-FileSpecificity)
> 
> Thanks,  
> Matt Ray  
> Senior Technical Evangelist | Opscode Inc.  
> [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> Twitter, IRC, GitHub: mattray
> 
> On Fri, Jun 3, 2011 at 2:27 PM, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:
> 
> > This is not always the default - it's going to be a reflection of the  
> > user who runs chef's umask. Most operating systems will have this be  
> > 0600, but not all of them will - so you can't rely on it as a general  
> > rule.
> > 
> > Adam
> > 
> > On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:
> > 
> > > I verified this and I've updated the Template entry on the Resources  
> > > page to reflect the default.  
> > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)
> > > 
> > > Thanks,  
> > > Matt Ray  
> > > Senior Technical Evangelist | Opscode Inc.  
> > > [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> > > Twitter, IRC, GitHub: mattray
> > > 
> > > On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:
> > > 
> > > > It appears that if one does not specify a mode,  
> > > > files generated/overwritten by template resources  
> > > > end up having permissions like -rw------- (0600).
> > > > 
> > > > This seems like a sane default. But maybe the  
> > > > documentation should make this explicit.  
> > > > Right now, the template resource wiki page  
> > > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> > > > reads:
> > > > 
> > > > Attribute: mode  
> > > > Description: "The octal mode of the file - 0755"  
> > > > Default Value: (nothing here)
> > > > 
> > > > Take for example the simple case of managing /etc/hosts.  
> > > > This file usually has permissions -rw-r--r--.
> > > > 
> > > > template '/etc/hosts'  
> > > > source 'hosts.erb'  
> > > > end
> > > > 
> > > > .. will overwrite /etc/hosts as expected, but if one  
> > > > forgets to pass in the mode attribute, '/etc/hosts'  
> > > > ends up as readable only by root (i.e., -rw-------).
> > > > 
> > > > This is not really a major problem (I simply make sure  
> > > > to pass in a mode explicitly).  
> > > > but as a suggestion:
> > > > 
> > > > (1) For existing files that get 'templated',  
> > > > chef-client could just leave the permissions untouched.
> > > > 
> > > > OR
> > > > 
> > > > (2) Fix the docs to make it very clear that unless  
> > > > one specifies a mode explicitly, the file  
> > > > created/overwritten by the template will end up  
> > > > with the default mode (and that the default  
> > > > mode is 0600, not 0755)
> > > > 
> > > > For the record, I'm still running 0.9.16.
> > > > 
> > > > Thanks,  
> > > > Faiz
> > 
> > --  
> > Opscode, Inc.  
> > Adam Jacob, Chief Product Officer  
> > T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

--  
Opscode, Inc.  
Adam Jacob, Chief Product Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![Faiz\_Kazi](https://avatars.discourse-cdn.com/v4/letter/f/35a633/32.png) [@Faiz\_Kazi](https://discourse.chef.io/u/Faiz_Kazi)\
**Post date:** [June 5, 2011, 6:44am UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/6 "2011-06-05T06:44:58Z")

</div>

Ah, I see.

What about suggestion (1), though? I think it might  
be a less of a surprise to users if the effect  
of applying a template resource respected the original  
mode of the file (in the absence of a mode attribute).

If requesting such a change in behavior is not an  
option, it would still be useful for the wiki to  
explicitly mention the umask defaults that apply  
in the absence of a mode.

(I'm happy to do the wiki edit if it's too much of a bother)

Faiz

On Fri, 3 Jun 2011 12:27:16 -0700  
Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

> This is not always the default - it's going to be a reflection of the  
> user who runs chef's umask. Most operating systems will have this be  
> 0600, but not all of them will - so you can't rely on it as a general  
> rule.
> 
> Adam
> 
> On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:
> 
> > I verified this and I've updated the Template entry on the Resources  
> > page to reflect the default.  
> > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)
> > 
> > Thanks,  
> > Matt Ray  
> > Senior Technical Evangelist | Opscode Inc.  
> > [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> > Twitter, IRC, GitHub: mattray
> > 
> > On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp)  
> > wrote:
> > 
> > > It appears that if one does not specify a mode,  
> > > files generated/overwritten by template resources  
> > > end up having permissions like -rw------- (0600).
> > > 
> > > This seems like a sane default. But maybe the  
> > > documentation should make this explicit.  
> > > Right now, the template resource wiki page  
> > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> > > reads:
> > > 
> > > Attribute: mode  
> > > Description: "The octal mode of the file - 0755"  
> > > Default Value: (nothing here)
> > > 
> > > Take for example the simple case of managing /etc/hosts.  
> > > This file usually has permissions -rw-r--r--.
> > > 
> > > template '/etc/hosts'  
> > > source 'hosts.erb'  
> > > end
> > > 
> > > .. will overwrite /etc/hosts as expected, but if one  
> > > forgets to pass in the mode attribute, '/etc/hosts'  
> > > ends up as readable only by root (i.e., -rw-------).
> > > 
> > > This is not really a major problem (I simply make sure  
> > > to pass in a mode explicitly).  
> > > but as a suggestion:
> > > 
> > > (1) For existing files that get 'templated',  
> > > chef-client could just leave the permissions untouched.
> > > 
> > > OR
> > > 
> > > (2) Fix the docs to make it very clear that unless  
> > > one specifies a mode explicitly, the file  
> > > created/overwritten by the template will end up  
> > > with the default mode (and that the default  
> > > mode is 0600, not 0755)
> > > 
> > > For the record, I'm still running 0.9.16.
> > > 
> > > Thanks,  
> > > Faiz

---

<div class="post-metadata">

**Author:** ![Bob\_Corsaro](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bob_corsaro/32/822_2.png) [@Bob\_Corsaro](https://discourse.chef.io/u/Bob_Corsaro)\
**Post date:** [June 5, 2011, 1:47pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/7 "2011-06-05T13:47:49Z")

</div>

That may be more confusing since many SCMs don't track file mode. Then there  
are different OSes with different schemes.

Sent from WOPR  
On Jun 5, 2011 2:45 AM, "Faiz Kazi" [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:

> Ah, I see.
> 
> What about suggestion (1), though? I think it might  
> be a less of a surprise to users if the effect  
> of applying a template resource respected the original  
> mode of the file (in the absence of a mode attribute).
> 
> If requesting such a change in behavior is not an  
> option, it would still be useful for the wiki to  
> explicitly mention the umask defaults that apply  
> in the absence of a mode.
> 
> (I'm happy to do the wiki edit if it's too much of a bother)
> 
> Faiz
> 
> On Fri, 3 Jun 2011 12:27:16 -0700  
> Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:
> 
> > This is not always the default - it's going to be a reflection of the  
> > user who runs chef's umask. Most operating systems will have this be  
> > 0600, but not all of them will - so you can't rely on it as a general  
> > rule.
> > 
> > Adam
> > 
> > On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:
> > 
> > > I verified this and I've updated the Template entry on the Resources  
> > > page to reflect the default.  
> > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)
> > > 
> > > Thanks,  
> > > Matt Ray  
> > > Senior Technical Evangelist | Opscode Inc.  
> > > [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> > > Twitter, IRC, GitHub: mattray
> > > 
> > > On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp)  
> > > wrote:
> > > 
> > > > It appears that if one does not specify a mode,  
> > > > files generated/overwritten by template resources  
> > > > end up having permissions like -rw------- (0600).
> > > > 
> > > > This seems like a sane default. But maybe the  
> > > > documentation should make this explicit.  
> > > > Right now, the template resource wiki page  
> > > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> > > > reads:
> > > > 
> > > > Attribute: mode  
> > > > Description: "The octal mode of the file - 0755"  
> > > > Default Value: (nothing here)
> > > > 
> > > > Take for example the simple case of managing /etc/hosts.  
> > > > This file usually has permissions -rw-r--r--.
> > > > 
> > > > template '/etc/hosts'  
> > > > source 'hosts.erb'  
> > > > end
> > > > 
> > > > .. will overwrite /etc/hosts as expected, but if one  
> > > > forgets to pass in the mode attribute, '/etc/hosts'  
> > > > ends up as readable only by root (i.e., -rw-------).
> > > > 
> > > > This is not really a major problem (I simply make sure  
> > > > to pass in a mode explicitly).  
> > > > but as a suggestion:
> > > > 
> > > > (1) For existing files that get 'templated',  
> > > > chef-client could just leave the permissions untouched.
> > > > 
> > > > OR
> > > > 
> > > > (2) Fix the docs to make it very clear that unless  
> > > > one specifies a mode explicitly, the file  
> > > > created/overwritten by the template will end up  
> > > > with the default mode (and that the default  
> > > > mode is 0600, not 0755)
> > > > 
> > > > For the record, I'm still running 0.9.16.
> > > > 
> > > > Thanks,  
> > > > Faiz

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [June 5, 2011, 5:02pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/8 "2011-06-05T17:02:33Z")

</div>

Yeah - if you don't specify a mode, we shouldn't be modifying it -  
that's definitely a bug, if we're behaving that way.

Adam

On Sat, Jun 4, 2011 at 11:44 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:

> Ah, I see.
> 
> What about suggestion (1), though? I think it might  
> be a less of a surprise to users if the effect  
> of applying a template resource respected the original  
> mode of the file (in the absence of a mode attribute).
> 
> If requesting such a change in behavior is not an  
> option, it would still be useful for the wiki to  
> explicitly mention the umask defaults that apply  
> in the absence of a mode.
> 
> (I'm happy to do the wiki edit if it's too much of a bother)
> 
> Faiz
> 
> On Fri, 3 Jun 2011 12:27:16 -0700  
> Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:
> 
> > This is not always the default - it's going to be a reflection of the  
> > user who runs chef's umask. Most operating systems will have this be  
> > 0600, but not all of them will - so you can't rely on it as a general  
> > rule.
> > 
> > Adam
> > 
> > On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:
> > 
> > > I verified this and I've updated the Template entry on the Resources  
> > > page to reflect the default.  
> > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)
> > > 
> > > Thanks,  
> > > Matt Ray  
> > > Senior Technical Evangelist | Opscode Inc.  
> > > [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> > > Twitter, IRC, GitHub: mattray
> > > 
> > > On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp)  
> > > wrote:
> > > 
> > > > It appears that if one does not specify a mode,  
> > > > files generated/overwritten by template resources  
> > > > end up having permissions like -rw------- (0600).
> > > > 
> > > > This seems like a sane default. But maybe the  
> > > > documentation should make this explicit.  
> > > > Right now, the template resource wiki page  
> > > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> > > > reads:
> > > > 
> > > > Attribute: mode  
> > > > Description: "The octal mode of the file - 0755"  
> > > > Default Value: (nothing here)
> > > > 
> > > > Take for example the simple case of managing /etc/hosts.  
> > > > This file usually has permissions -rw-r--r--.
> > > > 
> > > > template '/etc/hosts'  
> > > > source 'hosts.erb'  
> > > > end
> > > > 
> > > > .. will overwrite /etc/hosts as expected, but if one  
> > > > forgets to pass in the mode attribute, '/etc/hosts'  
> > > > ends up as readable only by root (i.e., -rw-------).
> > > > 
> > > > This is not really a major problem (I simply make sure  
> > > > to pass in a mode explicitly).  
> > > > but as a suggestion:
> > > > 
> > > > (1) For existing files that get 'templated',  
> > > > chef-client could just leave the permissions untouched.
> > > > 
> > > > OR
> > > > 
> > > > (2) Fix the docs to make it very clear that unless  
> > > > one specifies a mode explicitly, the file  
> > > > created/overwritten by the template will end up  
> > > > with the default mode (and that the default  
> > > > mode is 0600, not 0755)
> > > > 
> > > > For the record, I'm still running 0.9.16.
> > > > 
> > > > Thanks,  
> > > > Faiz

--  
Opscode, Inc.  
Adam Jacob, Chief Product Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![Faiz\_Kazi](https://avatars.discourse-cdn.com/v4/letter/f/35a633/32.png) [@Faiz\_Kazi](https://discourse.chef.io/u/Faiz_Kazi)\
**Post date:** [June 10, 2011, 7:57am UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/9 "2011-06-10T07:57:26Z")

</div>

On Sun, 5 Jun 2011 10:02:33 -0700  
Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

Here's an ad-hoc patch we use locally to address this problem  
(shown against v0.10).

Basically, mv was being used to move the rendered template  
to the resulting file. This has at least the following drawbacks:

1. mv may preserve mode/ownership, but the mode/ownership of  
the rendered template is not based on that of the original file.  
This means in the absence of an explicit mode, the file  
ends up with it's original mode modified (hence the bug)
2. SELinux - mv is trickier than cp.  
[http://www.centos.org/docs/5/html/Deployment\_Guide-en-US/rhlcommon-chapter-0017.html](http://www.centos.org/docs/5/html/Deployment_Guide-en-US/rhlcommon-chapter-0017.html)

Faiz

> Yeah - if you don't specify a mode, we shouldn't be modifying it -  
> that's definitely a bug, if we're behaving that way.
> 
> Adam
> 
> On Sat, Jun 4, 2011 at 11:44 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp)  
> wrote:
> 
> > Ah, I see.
> > 
> > What about suggestion (1), though? I think it might  
> > be a less of a surprise to users if the effect  
> > of applying a template resource respected the original  
> > mode of the file (in the absence of a mode attribute).
> > 
> > If requesting such a change in behavior is not an  
> > option, it would still be useful for the wiki to  
> > explicitly mention the umask defaults that apply  
> > in the absence of a mode.
> > 
> > (I'm happy to do the wiki edit if it's too much of a bother)
> > 
> > Faiz
> > 
> > On Fri, 3 Jun 2011 12:27:16 -0700  
> > Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:
> > 
> > > This is not always the default - it's going to be a reflection of  
> > > the user who runs chef's umask. Most operating systems will have  
> > > this be 0600, but not all of them will - so you can't rely on it  
> > > as a general rule.
> > > 
> > > Adam
> > > 
> > > On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:
> > > 
> > > > I verified this and I've updated the Template entry on the  
> > > > Resources page to reflect the default.  
> > > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)
> > > > 
> > > > Thanks,  
> > > > Matt Ray  
> > > > Senior Technical Evangelist | Opscode Inc.  
> > > > [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> > > > Twitter, IRC, GitHub: mattray
> > > > 
> > > > On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp)  
> > > > wrote:
> > > > 
> > > > > It appears that if one does not specify a mode,  
> > > > > files generated/overwritten by template resources  
> > > > > end up having permissions like -rw------- (0600).
> > > > > 
> > > > > This seems like a sane default. But maybe the  
> > > > > documentation should make this explicit.  
> > > > > Right now, the template resource wiki page  
> > > > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> > > > > reads:
> > > > > 
> > > > > Attribute: mode  
> > > > > Description: "The octal mode of the file - 0755"  
> > > > > Default Value: (nothing here)
> > > > > 
> > > > > Take for example the simple case of managing /etc/hosts.  
> > > > > This file usually has permissions -rw-r--r--.
> > > > > 
> > > > > template '/etc/hosts'  
> > > > > source 'hosts.erb'  
> > > > > end
> > > > > 
> > > > > .. will overwrite /etc/hosts as expected, but if one  
> > > > > forgets to pass in the mode attribute, '/etc/hosts'  
> > > > > ends up as readable only by root (i.e., -rw-------).
> > > > > 
> > > > > This is not really a major problem (I simply make sure  
> > > > > to pass in a mode explicitly).  
> > > > > but as a suggestion:
> > > > > 
> > > > > (1) For existing files that get 'templated',  
> > > > > chef-client could just leave the permissions untouched.
> > > > > 
> > > > > OR
> > > > > 
> > > > > (2) Fix the docs to make it very clear that unless  
> > > > > one specifies a mode explicitly, the file  
> > > > > created/overwritten by the template will end up  
> > > > > with the default mode (and that the default  
> > > > > mode is 0600, not 0755)
> > > > > 
> > > > > For the record, I'm still running 0.9.16.
> > > > > 
> > > > > Thanks,  
> > > > > Faiz

---

<div class="post-metadata">

**Author:** ![Brian\_Akins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brian_akins/32/298_2.png) [@Brian\_Akins](https://discourse.chef.io/u/Brian_Akins)\
**Post date:** [June 15, 2011, 12:02pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/10 "2011-06-15T12:02:36Z")

</div>

On Fri, Jun 10, 2011 at 3:57 AM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:

> Here's an ad-hoc patch we use locally to address this problem  
> (shown against v0.10).

Does cp truncate the target file then write it? I'd like to avoid that if  
possible. Some daemons don't like that.

---

<div class="post-metadata">

**Author:** ![Allan\_Wind](https://avatars.discourse-cdn.com/v4/letter/a/ac91a4/32.png) [@Allan\_Wind](https://discourse.chef.io/u/Allan_Wind)\
**Post date:** [June 15, 2011, 2:38pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/11 "2011-06-15T14:38:06Z")

</div>

On 2011-06-15 08:02:36, Brian Akins wrote:

> Does cp truncate the target file then write it? I'd like to avoid that if  
> possible. Some daemons don't like that.

$ 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

## /Allan

Allan Wind  
Life Integrity, LLC  
[http://lifeintegrity.com](http://lifeintegrity.com)

---

<div class="post-metadata">

**Author:** ![Brian\_Akins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brian_akins/32/298_2.png) [@Brian\_Akins](https://discourse.chef.io/u/Brian_Akins)\
**Post date:** [June 15, 2011, 3:43pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/12 "2011-06-15T15:43:29Z")

</div>

On Wed, Jun 15, 2011 at 10:38 AM, Allan Wind  
[allan\_wind@lifeintegrity.com](mailto:allan_wind@lifeintegrity.com)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.

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [June 15, 2011, 4:21pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/13 "2011-06-15T16:21:32Z")

</div>

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

> On Wed, Jun 15, 2011 at 10:38 AM, Allan Wind \<[allan\_wind@lifeintegrity.com](mailto:allan_wind@lifeintegrity.com) ([mailto:allan\_wind@lifeintegrity.com](mailto:allan_wind@lifeintegrity.com))\> 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

---

<div class="post-metadata">

**Author:** ![Faiz\_Kazi](https://avatars.discourse-cdn.com/v4/letter/f/35a633/32.png) [@Faiz\_Kazi](https://discourse.chef.io/u/Faiz_Kazi)\
**Post date:** [June 16, 2011, 2:25am UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/14 "2011-06-16T02:25:00Z")

</div>

On Wed, 15 Jun 2011 09:21:32 -0700  
Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> On Wednesday, June 15, 2011 at 8:43 AM, Brian Akins wrote:
> 
> > On Wed, Jun 15, 2011 at 10:38 AM, Allan Wind  
> > \<[allan\_wind@lifeintegrity.com](mailto:allan_wind@lifeintegrity.com)  
> > ([mailto:allan\_wind@lifeintegrity.com](mailto:allan_wind@lifeintegrity.com))\> 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.

cp's drawbacks - compared to mv - which are that  
(a) it is not atomic and  
(b) it truncates the file and then does a write  
with the new contents -

- are a problem in some case, sure. I think it  
depends on what kind of file is being template'd by  
chef.

One of the most frequent use cases is to automate  
the editing of config files - something that without  
chef, is done using a text editor. I'm guessing most  
editors simply do an open() with WRONLY|TRUNC, then  
write out the new contents. This is not any worse  
than cp.

Take ed for instance:

# test.txt contains only one line -\> "The first line.\n"

echo -e '$\na\n#a new line\n.\nwq\n' | strace ed test.txt

...  
open("test.txt", O\_WRONLY|O\_CREAT|O\_TRUNC, 0666) = 4

# fd=3 seems to be a temp. file in this case.

write(3, "#a new line", 11) = 11  
lseek(3, 0, SEEK\_SET) = 0  
read(3, "The first line.#a new line", 4096) = 26  
fstat(4, {st\_mode=S\_IFREG|0644, st\_size=0, ...}) = 0  
mmap(NULL, 4096, PROT\_READ|PROT\_WRITE, MAP\_PRIVATE|MAP\_ANONYMOUS, -1,  
0) = 0x7f44573a5000 write(4, "The first line.\n#a new line\n", 28) = 28  
close(4) = 0

So for the majority of config file updates,  
chef calling FileUtils.cp does not seem any worse than  
editing the files by hand. (It's probably the  
closest emulation of that behavior).

However, O\_TRUNC might be a problem in other cases;  
I haven't come across one yet, but it's probably just  
a matter of time.

> 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.

That's right... I think we're dealing with the classic  
difficulty of trying to ensure atomic file write operations  
in a cross-platform manner.

Are the chances of  
(a) a left-behind RANDOM\_SLUG breaking a system after such  
an extreme failure  
much smaller than:  
(b) a daemon being negatively impacted because of a  
non-atomic config file update?

If Yes, and if (a) gives up atomicity, well why not.

> 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.

That's indeed a tricky question. I lean towards not changing the  
property of a resource unless the change was specified, but I  
also share your discomfort about this: The problem is that  
there will remain an undocumented/unknown property of  
the system (in this case the mode of a file) which is  
vital to the system as a whole. (an unknown unknown)

Making the mode required could potentially do away with  
all the ambiguity; but then that would break so many  
recipes already in use.

One possible (though somewhat uncool) middle-ground approach would  
be to print a converge-time warning when initial system state does  
not match the resources' defaults - and continue the converge keeping  
the state unchanged - the risks of breaking a running system  
because a file suddenly became unreadable by a daemon are very real.

I do think that running systems should be left to depend on  
undocumented state. If a chef recipe worked well simply because say,  
a certain library needed by some part of the system just happened  
to be available, but this fact was never made explicit in the  
recipe - then that situation needs to be identified and fixed.  
(In this case, whether or not chef makes the the mode attribute  
required for files). It's a balance between that and the risk  
of breaking something in production.

Faiz

---

<div class="post-metadata">

**Author:** ![Faiz\_Kazi](https://avatars.discourse-cdn.com/v4/letter/f/35a633/32.png) [@Faiz\_Kazi](https://discourse.chef.io/u/Faiz_Kazi)\
**Post date:** [June 16, 2011, 10:08am UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/15 "2011-06-16T10:08:56Z")

</div>

On Thu, 16 Jun 2011 11:25:00 +0900  
Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:

> On Wed, 15 Jun 2011 09:21:32 -0700  
> I do think that running systems should be left to depend on  
> undocumented state. If a chef recipe worked well simply because say,

Typo. I meant:

I do think that running systems should _not_ be left to depend on  
undocumented state.

F

---

<div class="post-metadata">

**Author:** ![Brian\_Akins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brian_akins/32/298_2.png) [@Brian\_Akins](https://discourse.chef.io/u/Brian_Akins)\
**Post date:** [June 16, 2011, 12:51pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/16 "2011-06-16T12:51:50Z")

</div>

On Jun 15, 2011, at 10:25 PM, Faiz Kazi wrote:

> One of the most frequent use cases is to automate  
> the editing of config files - something that without  
> chef, is done using a text editor. I'm guessing most  
> editors simply do an open() with WRONLY|TRUNC, then  
> write out the new contents. This is not any worse  
> than cp.

Don't a lot of them write to a tmp file then mv it over? Also, mostly we used to rsync files around, which can be made to do updates atomically.

To me it seems lame to claim "it's no worse than " when the correct behavior is not incredibly hard to implement. My $.02 worth.

--Brian

---

<div class="post-metadata">

**Author:** ![Tim\_Diggins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tim_diggins/32/810_2.png) [@Tim\_Diggins](https://discourse.chef.io/u/Tim_Diggins)\
**Post date:** [July 27, 2011, 2:07pm UTC](https://discourse.chef.io/t/template-resource-default-value-for-mode-attribute/1887/17 "2011-07-27T14:07:59Z")

</div>

FYI - Because I misread (again) the notes on the wiki page as the default  
(and then found this on the web) I modified the wiki page to make it clear  
for all 'mode' options of resource that 0755 is not the default (and linked  
to Adam's reply within the list discussion)

HTH

Tim

On Fri, Jun 3, 2011 at 8:27 PM, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

> This is not always the default - it's going to be a reflection of the  
> user who runs chef's umask. Most operating systems will have this be  
> 0600, but not all of them will - so you can't rely on it as a general  
> rule.
> 
> Adam
> 
> On Fri, Jun 3, 2011 at 7:43 AM, Matt Ray [matt@opscode.com](mailto:matt@opscode.com) wrote:
> 
> > I verified this and I've updated the Template entry on the Resources  
> > page to reflect the default.  
> > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)
> > 
> > Thanks,  
> > Matt Ray  
> > Senior Technical Evangelist | Opscode Inc.  
> > [matt@opscode.com](mailto:matt@opscode.com) | (512) 731-2218  
> > Twitter, IRC, GitHub: mattray
> > 
> > On Thu, Jun 2, 2011 at 9:34 PM, Faiz Kazi [faiz@dreamarts.co.jp](mailto:faiz@dreamarts.co.jp) wrote:
> > 
> > > It appears that if one does not specify a mode,  
> > > files generated/overwritten by template resources  
> > > end up having permissions like -rw------- (0600).
> > > 
> > > This seems like a sane default. But maybe the  
> > > documentation should make this explicit.  
> > > Right now, the template resource wiki page  
> > > [http://wiki.opscode.com/display/chef/Resources#Resources-Template](http://wiki.opscode.com/display/chef/Resources#Resources-Template)  
> > > reads:
> > > 
> > > Attribute: mode  
> > > Description: "The octal mode of the file - 0755"  
> > > Default Value: (nothing here)
> > > 
> > > Take for example the simple case of managing /etc/hosts.  
> > > This file usually has permissions -rw-r--r--.
> > > 
> > > template '/etc/hosts'  
> > > source 'hosts.erb'  
> > > end
> > > 
> > > .. will overwrite /etc/hosts as expected, but if one  
> > > forgets to pass in the mode attribute, '/etc/hosts'  
> > > ends up as readable only by root (i.e., -rw-------).
> > > 
> > > This is not really a major problem (I simply make sure  
> > > to pass in a mode explicitly).  
> > > but as a suggestion:
> > > 
> > > (1) For existing files that get 'templated',  
> > > chef-client could just leave the permissions untouched.
> > > 
> > > OR
> > > 
> > > (2) Fix the docs to make it very clear that unless  
> > > one specifies a mode explicitly, the file  
> > > created/overwritten by the template will end up  
> > > with the default mode (and that the default  
> > > mode is 0600, not 0755)
> > > 
> > > For the record, I'm still running 0.9.16.
> > > 
> > > Thanks,  
> > > Faiz
> 
> --  
> Opscode, Inc.  
> Adam Jacob, Chief Product Officer  
> T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

## --

Tim Diggins  
[http://red56.co.uk](http://red56.co.uk)  
[tim@red56.co.uk](mailto:tim@red56.co.uk)

07515 931 642 / +447515931642