# Copy file to remote hosts in a module **URL:** \ **Category:** Ansible Project\ **Tags:** ansible-project\ **Created:** [August 3, 2012, 6:35pm UTC](https://forum.ansible.com/t/copy-file-to-remote-hosts-in-a-module/11760 "2012-08-03T18:35:00Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [August 3, 2012, 6:35pm UTC](https://forum.ansible.com/t/copy-file-to-remote-hosts-in-a-module/11760/1 "2012-08-03T18:35:00Z")
You could call the copy or template module earlier in your playbook, which of course is also doable if you are just using the API directly (though very very very few people do this). There is no way for a module to loop back to the control machine and say “before you continue, run this” You might want to look at the SSH key module (authorized\_key) which actually passes down the key as a string where in your playbook you could just use a Jinja2 key={% import path/to/keyfile-%} or however that looks to load the string source into the action string. ---
**Author:** ![David\_Rousselie](https://avatars.discourse-cdn.com/v4/letter/d/df788c/32.png) [@David\_Rousselie](https://forum.ansible.com/u/David_Rousselie)\ **Post date:** [August 6, 2012, 7:47am UTC](https://forum.ansible.com/t/copy-file-to-remote-hosts-in-a-module/11760/2 "2012-08-06T07:47:47Z")
The solution to make Jinja2 “read” the file and set the “key” variable with the content of the file seems to be the better option for now but I can’t make it works ☹ I tried something like : action: apt\_key key=“{% import file.key %}” uid=“key uid” but it does not work. Code between {% %} is not interpreted. How can I make Jinja interpret the import into a playbook ? Do you plan to implement a way to execute some part of module code locally (with access to the connection, to transfert files for example) ? I think, this would allow to have the same capabilities as internals modules like template, copy, … for externals modules. WDYT ? ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [August 6, 2012, 11:34am UTC](https://forum.ansible.com/t/copy-file-to-remote-hosts-in-a-module/11760/3 "2012-08-06T11:34:16Z")
"Doesn't work" ... Doesn't work how? How did you define "file?" Can you show me? There's probably something subtle to do. To what I think was your last question -- Ansible is not going to allow remote nodes to make decisions about how to control the central machine, no. Seems very wrong, dangerous, and complicated to do so. I'd prefer we concentrate on figuring out how to manipulate Jinja2 in this case than speculate on what if the architecture was the antithesis of itself. ---
**Author:** ![David\_Rousselie](https://avatars.discourse-cdn.com/v4/letter/d/df788c/32.png) [@David\_Rousselie](https://forum.ansible.com/u/David_Rousselie)\ **Post date:** [August 6, 2012, 3:47pm UTC](https://forum.ansible.com/t/copy-file-to-remote-hosts-in-a-module/11760/4 "2012-08-06T15:47:24Z")
> “Doesn’t work” … Doesn’t work how? > > How did you define “file?” Can you show me? There’s probably > something subtle to do. Here is more details : [https://gist.github.com/3275616](https://gist.github.com/3275616) There is the apt\_key module, a typical playbook that uses the apt\_key module and the output of test-module. As you can see, the “key” argument is not processed by jinja2. The result is the same with the actual ansible-playbook command line. > To what I think was your last question – Ansible is not going to > allow remote nodes to make decisions about how to control the central > machine, no. Seems very wrong, dangerous, and complicated to do so. > I’d prefer we concentrate on figuring out how to manipulate Jinja2 in > this case than speculate on > what if the architecture was the antithesis of itself. I was not thinking about controlling central machine from remote nodes but instead I was thinking about executing a module in multiple phases : - a first part of the module would be executed on the central machine for each remote nodes, for example with something like this : ./mymodule $JSON\_ARG $NODE\_CONNECTION\_PARAMS - a second part of the module would be the same as of now and would be executed on remote nodes In this scenario : - the central machine still have control over remote nodes and not the opposite which, I agree with you, has something wrong - in the first phase, the module can prepare remote nodes from the central machine (like uploading some resources needed in the second phases or pre-processing files with jinga2) - internal modules could be implemented the same way as other modules