Assuming copy content goes away, is there any way to simplify the template 
module? Right now if I want to copy a PEM cert from the vault onto a target 
host, I have to create a set of files such as cert.j2 and key.j2 with 
contents {{ cert }} and {{ key }} respectively, so now I have to manage two 
additional files in my repo.

On Monday, September 29, 2014 3:15:27 PM UTC-7, Jeffrey Wong wrote:
>
> Thanks for the clarification!
>
> I'll go ahead and use a template instead if that's what you're 
> recommending. It makes the most sense to deprecate/undocument content if 
> it's difficult to rectify strange differences with corner cases like that.
>
> Thanks!
>
> On Sunday, September 28, 2014 12:29:29 PM UTC-7, Michael DeHaan wrote:
>>
>> Those changes are related to some security fixes and various related 
>> changes as a result of those fixes that came later, all aimed at preventing 
>> unexpected argument insertion given untrusted data from remote hosts.
>>
>> So {{ foo }} is a request to insert something into a line, the way you 
>> have it above, and then ansible converts that into module arguments.
>>
>> I have considered just undocumenting the "content" parameter -- we're 
>> likely to do that -- as I think it leads to some confusing practices, 
>> better served by "template" in most cases.
>>
>> One of those examples is pushing an embedded shell script inside a 
>> playbook, when it could have been done in a one-liner with the "script" 
>> module.
>>
>> If you think you can fix it and still keep the argument detection/parsing 
>> in place, I'd be interested - but that's why it was closed with the reasons 
>> given, and why I suggested how to avoid this.
>>
>> The long form is also needed to pass structured data to modules, as is 
>> shown with the ec2 examples.
>>
>>
>>
>>
>>
>>
>> On Sat, Sep 27, 2014 at 1:08 PM, Jeffrey Wong <[email protected]> wrote:
>>
>>> Hi there!
>>>
>>> I noticed that ansible seemed to have done some updating with regards to 
>>> multiline variables, and I'm a little confused about the way the variables 
>>> are handled now.
>>>
>>> My use case comes from inserting private-key data into an encrypted yaml 
>>> file via ansible-vault, and printing the contents via copy module's content 
>>> directive. This worked great in 1.7.1, but with 1.7.2, it printed an extra 
>>> newline between each line. Coincidentally, when I next deployed via ansible 
>>> 1.7.2, my keys weren't working.
>>>
>>> The format is something like:
>>>
>>> group_vars/all.yml:
>>> key: |+
>>>   -----BEGIN PRIVATE KEY----
>>>   (private key)
>>>   (private key)
>>>   (private key)
>>>   -----END PRIVATE KEY-----
>>>
>>> roles/tasks/main.yml:
>>> - copy: content="{{ key }}" dest="/etc/ssl/private/key"
>>>
>>> 1.7.1 (correct):
>>> -----BEGIN PRIVATE KEY----
>>> (private key)
>>> (private key)
>>> (private key)
>>> -----END PRIVATE KEY-----
>>>
>>> 1.7.2 (incorrect):
>>> -----BEGIN PRIVATE KEY----
>>>
>>> (private key)
>>>
>>> (private key)
>>>
>>> (private key)
>>>
>>> -----END PRIVATE KEY-----
>>>
>>>
>>> While looking through the github issues, there was a ticket that 
>>> expressed exactly the issue I ran into:
>>> https://github.com/ansible/ansible/issues/9172
>>>
>>> And it was resolved by following the 'long' format from:
>>> https://github.com/ansible/ansible/issues/9067
>>>
>>> roles/tasks/main.yml (long format):
>>> - 
>>>   copy:
>>>     content: "{{ key }}"
>>>     dest: "/etc/ssl/private/key"
>>>
>>>
>>> However, these have since been closed as 'not a bug'.
>>>
>>> The way that multiline variables should not change no matter what format 
>>> the user is using. I do not understand the difference between the two 
>>> formats, why it should treat multiline variables differently, and how this 
>>> is not a bug. Can someone shed some light on this issue?
>>>
>>> Thanks!
>>>
>>> -- 
>>> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/ansible-project/2949f5ce-6f1b-40ec-bd79-1f2b83357e42%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/ansible-project/2949f5ce-6f1b-40ec-bd79-1f2b83357e42%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/8b37ad86-eafb-46da-a4d9-0ea4ed912b52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to