template requires write permission on parent directory?

[Jacob Weber]

I'm using the "template" task to modify a file that I own, and have write permissions on. I'm not using sudo; I'm just running it as my own user.

But I get an error "Destination [parent-dir] not writable." I'm guessing it's deleting and re-creating the file. Is there any way to avoid this, or do I need to give my user write permission on the parent directory?

JW

[Michael DeHaan]

The template module will need permissions to be able to write the template, however the template module is smart enough to not replace the file if the md5sum of the template has not changed.

IIRC, in some cases of sudo usage from non-root an md5sum isn't possible and it will need to try to overwrite it each time

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/50210aa7-c8be-4a01-aa72-27e845eec13a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jacob Weber]

Hi Michael. My user does have permission to write the file -- he just doesn't have permission to create files in the parent directory, and Ansible is complaining about that.

When the "template" task updates an existing file, does it delete and re-create the file?

JW

[Brian Coca]

Yes, template writes a new file and moves it into place.

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001

Pedo mellon a minno

[Jacob Weber]

I see, thanks. Could this be considered a bug? There may be cases where you want a user to have write permission on a file, but not the whole directory.

[Brian Coca]

it would require a major change to how template/file/assemble/etc work. In template's case the file is actually generated on the master and copied to the target machine.

ansible tries to make the change as atomic as possible (that is why it needs write to the dir) to make sure no other process reads the file in an inconsistent state.

[Jacob Weber]

That's disappointing. I'm going to have to re-think my permission scheme. But thanks for the info.

JW

[Ben Hoyt]

I'm running into this exact issue too. We thought we'd make permissions as tight as possible, but due to how atomic_move() works Ansible requires the parent directory to be writeable too.

Is there a best-practice workaround for this? Obviously one way is to just make the parent directory writeable, but without that? Is there a way to generate the template file locally and then copy it over in a non-atomic way so it just requires write permissions on that file? Similar to how you would be hand when editing the file with your favourite text editor?

-Ben

[Michael DeHaan]

I suppose it could be made to check if the parent dir did not have permissions and in such case open the file, clear the contents, and write data back into it, but this seems a little gross to me.

In particular, copy operations on large files would require loading everything into memory, wouldn't they?

Really this is the first time I've ever heard of this being a problem - not saying I'm not sympahethic - but it's interesting it has not been a request yet.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/cccc9357-c622-48eb-bb91-6afb54faeba6%40googlegroups.com.

[Ben Hoyt]

I suppose it could be made to check if the parent dir did not have permissions and in such case open the file, clear the contents, and write data back into it, but this seems a little gross to me.

I think that would be "gross" if it weren't explicit. What about an explicit nonatomic=yes or overwrite=yes option that enables this? The default would be no (the current behaviour), and the docs could say something like, "by default, Ansible does an atomic move and requires write permission on the file's directory to allow it to create a temporary file; if this option is turned on, the copy is non-atomic and write permission on the directory in not required".

 

In particular, copy operations on large files would require loading everything into memory, wouldn't they?

I haven't dived very deep on how atomic_move is implemented, but why would doing this change the memory requirements?

Really this is the first time I've ever heard of this being a problem - not saying I'm not sympahethic - but it's interesting it has not been a request yet.

Two requests in two months on this mailing list. ;-)

Don't worry, we'll be working around this by slightly looser permissions in the meantime.

-Ben

[Dick Davies]

On 23 June 2014 19:44, Ben Hoyt <ben...@gmail.com> wrote:

> I haven't dived very deep on how atomic_move is implemented, but why would
> doing this change the memory requirements?

Because you'd have to read in the source file to be able to 'cat' it
into the truncated
destination file, rather than just moving it into place
(which requires the directory to be updated, therefore writable).

[Tomasz Kontusz]

Dick Davies <di...@hellooperator.net> napisał:

Typically you'd read a block or a few, write that, get the next one... Repeat until end of source file.

--
Wysłane za pomocą K-9 Mail.

[Michael DeHaan]

I find the concept of having to specify a parameter like nonatomic or overwrite a bit arcane for this, as it doesn't really describe what is being done.

My gut feeling is the present behavior is acceptable, if the files were not there, ansible would need to create the file anyway, as is it's nature.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/a0e99bef-415e-4b47-91a2-8daedb9cb317%40email.android.com.

[Ben Hoyt]

 

if the files were not there, ansible would need to create the file anyway, as is it's nature

That's a fair point. If ansible is being used for end-to-end server configuration (as is often the case) it will have to create the file anyway.

However, one thing that could be improved here is the documentation -- mention in the "template" (and "copy"?) module docs that write access on the directory is required and why (due to the atomic temp file/rename magic).

-Ben

[Michael DeHaan]

Or perhaps improve the error message when it fails, yes.

Agreed.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAL9jXCH5%2B9fgCQB24tRsPPyDoiEpBEiOcCoSKBAZTf09WSXQ8Q%40mail.gmail.com.

[Ben Hoyt]

Ah yes -- good point. For me the error message was the first point of contact, and I was confused by it. It said:

Destination /etc/nginx/conf.d not writable

And my thought (till I looked at the Ansible source) was "why does the directory need to be writable when I'm just copying the existing file /etc/nginx/conf.d/upstream.conf?" Perhaps change the error message to something like:

Destination's parent directory %s not writable (must be writable for atomic file move)

-Ben

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/m5-obFecmd0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxidNdEzLeeZ_FhZ1_aJD8S4UHGf2FjPNSoAQ3PkD2qWg%40mail.gmail.com.

[Jacob Weber]

I'd actually like to see some general information in the documentation about this topic of user permissions. I would think that a lot of people get the idea to create users with limited sudo rights, and use them with Ansible. But there are cases like this where Ansible doesn't allow that. It would be good to know that up front, so you can think about how you want to handle permissions. If the recommendation is that Ansible always be run as a user with full sudo rights, that should be stated somewhere.

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/m5-obFecmd0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxidNdEzLeeZ_FhZ1_aJD8S4UHGf2FjPNSoAQ3PkD2qWg%40mail.gmail.com.

[Ben Hoyt]

Good point. We are in fact running our scripts as a user with limited sudo rights, so it's good to know that's not recommended practice.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6CB67A5A-6B9F-4BB4-8756-B857C5597411%40jacobweber.com.

[Michael DeHaan]

That's actually in the docs in the "note" section under http://docs.ansible.com/intro_adhoc.html#id8 where sudo is first introduced.

On Tue, Jun 24, 2014 at 10:42 AM, Jacob Weber <ja...@jacobweber.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6CB67A5A-6B9F-4BB4-8756-B857C5597411%40jacobweber.com.

[Michael DeHaan]

Then it sounds like the existing error message does indicate the directory needs to be writeable which may be good enough, I'm not sure whether most people would know or should need to know what "atomic move" was.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAL9jXCGKj0z%3DfajdCo-jD%3DdJ%2BYo1n6%3DHFe9muBj8etyQsH5y6g%40mail.gmail.com.

[Ben Hoyt]

Re note in docs -- thanks!

Then it sounds like the existing error message does indicate the directory needs to be writeable which may be good enough, I'm not sure whether most people would know or should need to know what "atomic move" was.

Well, as is it was confusing to me why it'd need access to the parent dir. I think even just a tweak would be helpful: Destination %2 -> Destination's parent directory %2

-Ben

[Indra Gunawan]

This is somewhat limiting to set directory to writable from 755 for instance to 775 so user running ansible can use template to replace file especially "service" startup file in /etc/init.d.  Even if my user is already using can "become" as root to write the file.