Hi.
I have a vars/foo.yml file that contains:
foo: |
How about not using the silly content parameter?
It’s really intended for exceedingly basic one-liner things, and as you know in Ansible that value will get templated out to form a command line to the module, so having weird newlines in there, without the variable, wouldn’t make much sense anyway.
Using the “template” module can also be a great solution if you want to trivially just push some value in to the remote side.
Alternatively:
copy:
content: “{{ value }}”
dest: foo
Will pass things along without trying to go through the line-oriented parsing.
Yes, as I mentioned in my mail, that's the workaround I'm already using.
I do think the documentation should mention something about when to not
use key=value syntax, though.
I find copy's "content" parameter quite convenient to put things like
policy-rc.d scripts and SSL keys from ansible-vault in place. But even
if we disregard that as silly, authorized_key's "key" parameter has
exactly the same problem with parsing.
The documentation for it uses key="{{ lookup … }}" _everywhere_, and
that breaks when your key file starts with «from="12.34.45.56", …»
(which is what github issue #6294 was about).
Would you take a patch to change all the example to use key: "…"
syntax instead?
-- ams
Changing all the examples would make very good since for the short term, though I believe we can also deal with fixing the \n issue.
I’m not aware of anything wrong with the key parameter, usually that’s one entry per line anyway, and also only used with a single line, but multiple lines don’t hurt that file IIRC.
Changing all the examples would make very good since for the short
term, though I believe we can also deal with fixing the \n issue.
OK, I'll submit a pull request to change the examples.
I'm not aware of anything wrong with the key parameter, usually that's
one entry per line anyway, and also only used with a single line, but
multiple lines don't hurt that file IIRC.
No, the problem with authorized_key's key= is not multiple lines, but
quoting. For example, if you want to install the following key:
from="1.2.3.4",command="rsync --server -logDtpre.iLsf --delete . foo/",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa …
using something like:
authorized_key: user=foo key="{{ lookup('file', …) }}"
Then you get:
fatal: [localhost] => A variable inserted a new parameter into the
module args. Be sure to quote variables if they contain equal signs (for
example: "{{var}}").
This has come up a few times, including in the bug report that I linked
to in my earlier post. For this problem, too, using the "key: value"
syntax makes the problem go away. So I'll change those examples too.
Independent of that, if you want to outline your approach to solving the
\n and quoting problems, I'd be happy to work on them.
-- ams