[[chef-dev]] Re: [[chef-dev]] CHEF-1621 - "recursive" attribute on "directory" resource does not apply users and groups to entire path

Chronological Thread 
  • From: Thomas Bishop < >
  • To: Chad Woolley < >
  • Cc:
  • Subject: [[chef-dev]] Re: [[chef-dev]] CHEF-1621 - "recursive" attribute on "directory" resource does not apply users and groups to entire path
  • Date: Sun, 3 Oct 2010 17:08:43 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=kVx3b69e1z8AoBvoSPJ9JOcPWs3oxrHy5CvK8HklbNWqqfbvJ6XX9DvJmSTU4YxKFI OzIrk4mUIPalmgm6i9Wr5p84U9+JTRA8K7OmBKD9f/IX2BdlsQfFxwPqqbkFAD9DimE+ VHCT6e32HyAu7yBLr90UTjQXOyLoMTDEOU5DY=

I see your perspective in the case of a new directory.

Given the user's example, my initial expectation is that I would have
to do the following:

directory "/data/realtime/fetched/radar" do
  action :create
  owner "ldm"
  group "ldm"
  mode "777"

directory "/data" do
  action :create
  owner "ldm"
  group "ldm"
  mode "777"
  recursive true

To me, this is more clear of what should happen.  I think there are a
couple of items that lead me to this.

1.  I'm probably influenced by how I would do this on the command
line. (mkdir -p /data/realtime/fetched/radar; chmod -R 777 /data;
chown -R ldm:ldm /data;)

2.  When I see 'recursive', I think of impacting down the tree of the
argument specified and not up.  Again, probably influenced by the
behavior of command line tools (cp -R, chmod -R, chown -R, etc.).

I guess another approach could be to have an attribute which denotes
to apply the ownership/permission settings to the entire path or
perhaps at a specific starting part.  Although this could be confusing
as well in combination with the recursive attribute.  Maybe change the
recursive attribute from a boolean to fit this type of functionality?
I don't care for either of these approaches too much.

I think this might just be a preference of implicit vs. explicit.

Personally, for something like file system
hierarchies/ownership/permissions I would prefer explicit definition.



On Sat, Oct 2, 2010 at 19:02, Chad Woolley 
< >
> On Sat, Oct 2, 2010 at 4:22 PM, Thomas Bishop 
> < >
>  wrote:
>> Hi folks,
>> I was discussing this ticket with Dan DeLeo on irc and we thought it
>> would be a good idea to get feedback from a larger audience.
>> Have a look at the example at http://tickets.opscode.com/browse/CHEF-1621.
>> The user was expecting:
>> 777 ldm:ldm /data
>> 777 ldm:ldm /data/realtime
>> 777 ldm:ldm /data/realtime/fetched
>> 777 ldm:ldm /data/realtime/fetched/radar
>> Here's what chef did:
>> 755 root:root /data
>> 755 root:root /data/realtime
>> 755 root:root /data/realtime/fetched
>> 777 ldm:ldm /data/realtime/fetched/radar
>> The current chef behavior makes sense to me.  Here are a couple of reasons 
>> why:
>> 1.  As the directory being defined is /data/realtime/fetched/radar, I
>> would not expect chef to touch the ownership or permissions on
>> anything above it.  I would however expect chef to create the required
>> parent directories if they did not exist in order to satisfy the
>> desired state.
>> 2.  If chef modified the permissions/ownership for the entire
>> structure, this could have adverse effects if there were additional
>> directories defined under /data, or /data/realtime or
>> /data/realtime/fetched.  If /data/foo existed for example.  In my
>> opinion, this would be counterintuitive behavior.
>> I agree with the ticket submitter that the docs aren't 100% clear on
>> this and should probably be updated.
>> I would love to hear additional thoughts on this.
> That makes sense, if the tree already exists.  You don't want to muck
> with existing permissions.
> However, if the parent directory hierarchy were being created from
> scratch (did not already exist), what should happen?  Should they be
> owned by root, or by the owner of the file at the bottom of the
> hierarchy?
> I think the latter makes sense, otherwise you'd have to explicitly
> create every level in the hierarchy and assign permissions.  That'd be
> silly.
> -- Chad

Archive powered by MHonArc 2.6.16.