as we all know, recursive true attribute of Directory resource, does not
recursively create the directories with the owner that you mention in the
resource,
I wonder what is the logical reason behind this design ?
and I also wonder if there is a recursive_directory resource I can use ? so
it just creates all the directories recursively with the user and owner
that I mention .
My guess is that since one or more of the folder in that path structure may already exist and be acl’d by other means.
The “workaround” is to specify the directories where you want the acl’s defined.
It is more work, but forces you to be explicit about the settings you want controlled and it is work that is done once.
Other concerns with changing acls up the directory tree - do you only set the permissions on folders Chef creates? Or do you re-acl everthing in the path that is defined?
There are a number of potential problems with setting acls on an undetermined number of ancestor directories as a general practice.
Steve
Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.com [http://stevenmurawski.com/]
On 3/13/2015 2:34:39 PM, Medya medya.gh@gmail.com wrote:
as we all know, recursive true attribute of Directory resource, does not recursively create the directories with the owner that you mention in the resource,
I wonder what is the logical reason behind this design ?
and I also wonder if there is a recursive_directory resource I can use ? so it just creates all the directories recursively with the user and owner that I mention .
This is an oldie by goodie.
It's been discussed a fair amount of times, and the documentation reflects
the current behavior:
Namely, directing the user to specify all directories in the path they want
the permissions scheme to apply in an Array.
-M
On Fri, Mar 13, 2015 at 5:26 PM, Steven Murawski steven.murawski@gmail.com
wrote:
My guess is that since one or more of the folder in that path structure
may already exist and be acl'd by other means.The "workaround" is to specify the directories where you want the acl's
defined.It is more work, but forces you to be explicit about the settings you want
controlled and it is work that is done once.Other concerns with changing acls up the directory tree - do you only set
the permissions on folders Chef creates? Or do you re-acl everthing in the
path that is defined?There are a number of potential problems with setting acls on an
undetermined number of ancestor directories as a general practice.Steve
Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.comOn 3/13/2015 2:34:39 PM, Medya medya.gh@gmail.com wrote:
as we all know, recursive true attribute of Directory resource, does not
recursively create the directories with the owner that you mention in the
resource,I wonder what is the logical reason behind this design ?
and I also wonder if there is a recursive_directory resource I can use ?
so it just creates all the directories recursively with the user and owner
that I mention .
I like the idea to be explicit .... but sometimes the user passes an
attribute you have no idea it is gonna be recursive
for example, imagine you have a recipe to create a user with a specific
home directory
user "blahblah" do
home "/some/recursive/path/which/user/gave/me/as/attribute"
action create
end
you have to create this path before u can specify it as a user home
directory
On Fri, Mar 13, 2015 at 4:52 PM, Mike miketheman@gmail.com wrote:
This is an oldie by goodie.
It's been discussed a fair amount of times, and the documentation reflects
the current behavior:
directory ResourceNamely, directing the user to specify all directories in the path they
want the permissions scheme to apply in an Array.-M
On Fri, Mar 13, 2015 at 5:26 PM, Steven Murawski <
steven.murawski@gmail.com> wrote:My guess is that since one or more of the folder in that path structure
may already exist and be acl'd by other means.The "workaround" is to specify the directories where you want the acl's
defined.It is more work, but forces you to be explicit about the settings you
want controlled and it is work that is done once.Other concerns with changing acls up the directory tree - do you only set
the permissions on folders Chef creates? Or do you re-acl everthing in the
path that is defined?There are a number of potential problems with setting acls on an
undetermined number of ancestor directories as a general practice.Steve
Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.comOn 3/13/2015 2:34:39 PM, Medya medya.gh@gmail.com wrote:
as we all know, recursive true attribute of Directory resource, does not
recursively create the directories with the owner that you mention in the
resource,I wonder what is the logical reason behind this design ?
and I also wonder if there is a recursive_directory resource I can use ?
so it just creates all the directories recursively with the user and owner
that I mention .
you should read the email archive on why the current behavior is preferred,
this has been answered several times. parent directory creation is governed
by umask etc, also modes for the parent directory might not be same as the
mode specified against the child directory.
On Fri, Mar 13, 2015 at 3:08 PM, Medya medya.gh@gmail.com wrote:
I like the idea to be explicit .... but sometimes the user passes an
attribute you have no idea it is gonna be recursive
for example, imagine you have a recipe to create a user with a specific
home directoryuser "blahblah" do
home "/some/recursive/path/which/user/gave/me/as/attribute"
action create
endyou have to create this path before u can specify it as a user home
directoryOn Fri, Mar 13, 2015 at 4:52 PM, Mike miketheman@gmail.com wrote:
This is an oldie by goodie.
It's been discussed a fair amount of times, and the documentation
reflects the current behavior:
directory ResourceNamely, directing the user to specify all directories in the path they
want the permissions scheme to apply in an Array.-M
On Fri, Mar 13, 2015 at 5:26 PM, Steven Murawski <
steven.murawski@gmail.com> wrote:My guess is that since one or more of the folder in that path
structure may already exist and be acl'd by other means.The "workaround" is to specify the directories where you want the acl's
defined.It is more work, but forces you to be explicit about the settings you
want controlled and it is work that is done once.Other concerns with changing acls up the directory tree - do you only
set the permissions on folders Chef creates? Or do you re-acl everthing in
the path that is defined?There are a number of potential problems with setting acls on an
undetermined number of ancestor directories as a general practice.Steve
Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.comOn 3/13/2015 2:34:39 PM, Medya medya.gh@gmail.com wrote:
as we all know, recursive true attribute of Directory resource, does not
recursively create the directories with the owner that you mention in the
resource,I wonder what is the logical reason behind this design ?
and I also wonder if there is a recursive_directory resource I can use ?
so it just creates all the directories recursively with the user and owner
that I mention .
I tried to search in mailing list on the website, the search function
doesnt work anymore, and I don't have all the old emails.
On Fri, Mar 13, 2015 at 6:47 PM, Ranjib Dey dey.ranjib@gmail.com wrote:
you should read the email archive on why the current behavior is
preferred, this has been answered several times. parent directory creation
is governed by umask etc, also modes for the parent directory might not be
same as the mode specified against the child directory.On Fri, Mar 13, 2015 at 3:08 PM, Medya medya.gh@gmail.com wrote:
I like the idea to be explicit .... but sometimes the user passes an
attribute you have no idea it is gonna be recursive
for example, imagine you have a recipe to create a user with a specific
home directoryuser "blahblah" do
home "/some/recursive/path/which/user/gave/me/as/attribute"
action create
endyou have to create this path before u can specify it as a user home
directoryOn Fri, Mar 13, 2015 at 4:52 PM, Mike miketheman@gmail.com wrote:
This is an oldie by goodie.
It's been discussed a fair amount of times, and the documentation
reflects the current behavior:
directory ResourceNamely, directing the user to specify all directories in the path they
want the permissions scheme to apply in an Array.-M
On Fri, Mar 13, 2015 at 5:26 PM, Steven Murawski <
steven.murawski@gmail.com> wrote:My guess is that since one or more of the folder in that path
structure may already exist and be acl'd by other means.The "workaround" is to specify the directories where you want the acl's
defined.It is more work, but forces you to be explicit about the settings you
want controlled and it is work that is done once.Other concerns with changing acls up the directory tree - do you only
set the permissions on folders Chef creates? Or do you re-acl everthing in
the path that is defined?There are a number of potential problems with setting acls on an
undetermined number of ancestor directories as a general practice.Steve
Steven Murawski
Community Software Development Engineer @ Chef
Microsoft MVP - PowerShell
http://stevenmurawski.comOn 3/13/2015 2:34:39 PM, Medya medya.gh@gmail.com wrote:
as we all know, recursive true attribute of Directory resource, does
not recursively create the directories with the owner that you mention in
the resource,I wonder what is the logical reason behind this design ?
and I also wonder if there is a recursive_directory resource I can use
? so it just creates all the directories recursively with the user and
owner that I mention .
On Mar 13, 2015, at 12:33 PM, Medya medya.gh@gmail.com wrote:
as we all know, recursive true attribute of Directory resource, does not recursively create the directories with the owner that you mention in the resource,
I wonder what is the logical reason behind this design ?
and I also wonder if there is a recursive_directory resource I can use ? so it just creates all the directories recursively with the user and owner that I mention .
The behavior roughly mirrors that of mkdir -p, which is the closest you'll get to an expected semantic for this.
--Noah
On 3/13/15 12:33 PM, Medya wrote:
as we all know, recursive true attribute of Directory resource, does
not recursively create the directories with the owner that you mention
in the resource,I wonder what is the logical reason behind this design ?
and I also wonder if there is a recursive_directory resource I can use
? so it just creates all the directories recursively with the user and
owner that I mention .
Its not an idempotent feature.
Ideally 'recursive true' would not exist, and that would force you to,
one way or another, create individual directory resources from the
parent where you expected the permissions management to start up to the
final directory you wanted to create.
If you've got this:
directory "/var/www/app/foo" do
owner "www"
group "www"
recursive true
end
Should the perms on /var be www:www? (probably not). Should the perms
on /var/www/app be www:www:? (probably). How can that directory
resource know which ones you intend? When its first created then
probably only /var or /var/www already exist, and you want the perms to
apply at all the newly created directories -- but if I "chown root
/var/www/app" then it should be fixed right? but now when I "chown root
/var"? Chef doesn't remember where it created the directories from so
there's no way to know where to start managing the file perms.
And you clearly care about those intermediate perms, or else you
wouldn't be asking the question, so if the permissions are mangled at
some point you want Chef reverting the changes, but it doesn't have the
information it needs.
OTOH there is no ambiguity here about what you want and this is what you
have to do:
%w[ /var/www /var/www/app /var/www/app/foo ].each do |path|
directory path do
owner "www"
group "www"
end
end
Lamont, you recently wrote about this topic: “we want to preserve mkdir -p semantics”
it seems the two most common examples of mkdir -p are:
Case 1: In directory /home/test, logged in as user test. Then mkdir -p dir1/dir2/dir3 . The resulting directories dir1/dir2/dir3 are all owned by test.
Case 2: In directory /etc, logged in as user root. Then mkdir -p dir1/dir2/dir3 . The resulting directories dir1/dir2/dir3 are all owned by root.
The hybrid solution that chef is doing creates the ownership as root/root/test . What are some common use cases of that (root/root/root/user) and are they actually more frequent than the two examples mentioned above?
the current recursive attribute isn’t preserving mkdir -p semantics. The way that it could, would be to create the directories with the expected ownership, as in Case 1 just mentioned, and in a sort of lazy fashion. (i.e., if the directory already exists, then just keep going, and don’t modify it.) Subsequently, do not monitor or enforce the ownership in the intermediate folders, just leave the intermediate folders as-is.
"just be explicit about the dirs"
Sometimes, in a dynamic code environment, you might not know the depth or the names of the recursive dirs, ahead of time.
Maybe the simplest solution for end-users is to create a bash resource, and run “mkdir -p”.
I just don't find that argument compelling. Find a way to rearchitect so that you understand what directories you need to control and explicitly control them. If you can't do that, you will /always/ have issues on the second run with not understanding where you need to start fixing permissions from. So the assumptions in your argument start from what I consider to be a fundamentally losing position--and you are unlikely to make them accept them.
That goes back to my argument that we never should have created the recursive attribute in the first place and should have absolutely forced you to understand your system better.
Anyway, and edge case of "sometimes with dynamic code" I can't find compelling. You'll have to get more specific. I've been doing "dynamic code" config management for more than 16 years now and don't see the use case where refactoring to better understand what you need to manage wouldn't be better.
I also disagree with your argument. If you are logged in as the 'test' user and run chef-client then all the directories will be owned by test, just like with mkdir -p. The result of the directory resource is the same as the result of a mkdir -p followed by a chown on the directory when run as the root user. The behavior is correct. If you leave off the perms on the resource then you recover mkdir -p run as root.
And if you've really found the one edge case where the recursive attribute is wrong and you can't replace it with multiple explicit directory resources (which really you could write your own code to discover the first directory that doesn't exist and then use that as a floor, so I'm kinda positive you haven't found it), then you really should just use an execute resources. That's what those are kinda there for -- the 1% of the time where the declarative resources in chef don't match the use case, but you just need to get the job done -- but we generally don't refactor core chef around those cases...
This feature is only a very small detail, but it's fun to chat about, so will post a reply anyway.
Find a way to rearchitect so that you understand what directories you need to control and explicitly control them.
In our case the first directory is known, it is writable, and the fix that I posted last time works: the simplest solution is to create a bash resource, and run "mkdir -p". (with user/group set on the bash resource). Done. Or multiple standard chef dir resources.
But when provisioning code from developers, you don't necessarily know in advance a particular dir depth, and would like to handle arbitrary/unknown cases with the recursive flag, it's a convenience method.
If you are logged in as the 'test' user and run chef-client
Most of the chef supermarket cookbooks are non-trivial and must have permissions to install packages and so on, right? It's pretty standard to run chef-client as root. "The default configuration of the chef-client assumes that it is run as the root user."
At the same time, the fact it's run as root, isn't meant to strongly convey a datapoint, that we definitely prefer all files to be owned by the same user who is running chef-client. Ok, as a default permission, yes. But it should be easily over-ridden. And that's what the user and group properties of the resource are for. In this context, running chef-client is different from running a plain old bash command, because in the latter case, there is a more reasonable assumption that you want the user/group values of the executing user to be applied, whereas chef-client almost always has to be run as root, but it doesn't imply that you intend everything in the cookbooks to be owned by root. The root/root ownership should be more of a "weak default value", than a "strong default value", and easily over-ridden, because chef-client sort of has to be run as root.
the one edge case where the recursive attribute is wrong
the 1% of the time
The percentages should be swapped, with 1% applying to the current implementation. 
How often do actually prefer and expect the intermediate dirs to be root instead of the assigned user/group property? the cookbook author never specified 'root', that is merely a coincidence, an accident, because you have to run chef as root.