With ssh forwarding turned off and even if we turn it on for the time being, bastion doesn't support agent forwarding. So, the easiest way to do it right now, become root on batcave and scp the content to batcave as root and then from there copy to another host.
This is very convoluted for a simple task. It would be greatly beneficial to have a playbook to copy content from host A to host B.
Not urgent (but can we add this as an easy task)
Metadata Update from @zlopez: - Issue tagged with: easyfix, low-trouble, medium-gain
Metadata Update from @zlopez: - Issue tagged with: groomed
Metadata Update from @zlopez: - Issue priority set to: Waiting on Assignee (was: Needs Review)
Metadata Update from @nb: - Issue assigned to hyperreal
The more I think about it, maybe a shell/python script running as root on batcave seems like an easier option as root on batcave has ssh access to all the infra.
What could a shell/python script accomplish that scp from root on batcave cannot? Are the files that need to be copied always going to be the same? A shell script would seem to be suitable if it will always copy contents from, say, /tmp/staging to specified hosts. Will it always be the same host(s), or would you like to supply the hosts as an argument to the shell script?
I am planning to supply two hosts and two locations (one for source and one for dest). So, the source file or source dir on source host needs to be copied to dest location on dest host. root on batcave have ssh access to all the hosts, which is why I thought a script might be useful rather than having to copy from batcave all the time.
Sounds good. I'll get to work on it.
Does this work? https://gist.github.com/hyperreal64/e861a40768248c958725d1e893386ab2
I am not sure if delegate_to works since only the control_node has access to both the source and dest hosts.
delegate_to
I'll just write up a script. The script would take two arguments, one for src host and directory and the other for dest host and directory.
https://www.middlewareinventory.com/blog/how-to-copy-files-between-remote-servers-ansible-fetch-sync/
https://docs.ansible.com/ansible/latest/modules/synchronize_module.html
@amrmostafazaki Thanks!
@mohanboddu Does this work for you? https://gist.github.com/hyperreal42/e861a40768248c958725d1e893386ab2
This could work, I guess using --extra-vars to provide the arguments at runtime should work.
--extra-vars
@mohanboddu Does this work for you? https://gist.github.com/hyperreal64/e861a40768248c958725d1e893386ab2 This could work, I guess using --extra-vars to provide the arguments at runtime should work.
@mohanboddu Does this work for you? https://gist.github.com/hyperreal64/e861a40768248c958725d1e893386ab2
Would it be better to add those arguments into the playbook, or will they be different every time? If this is acceptable, how do I mark this issue as Closed, or does someone else do that?
They will be always different. So, its better to use --extra-vars
Sounds good!
@hyperreal did you manage to make some progress on this? Do you need some help?
As far as I know this was completed. I think @mohanboddu was satisfied with this playbook and using --extra_vars: https://gist.github.com/hyperreal64/e861a40768248c958725d1e893386ab2
--extra_vars
@hyperreal has it been added to our ansible repo: https://pagure.io/Fedora-Infra/ansible/ ?
If not, we should :)
I think the only issue with the --extra-vars argument is that rbac-playbook won't allow it for security reasons so this script could only be run by a sysadmin-main user on the batcave.
Agreed, though seeing the purpose of this playbook I'd think that it is fine in this case.
@hyperreal has it been added to our ansible repo: https://pagure.io/Fedora-Infra/ansible/ ? If not, we should :)
No problem. How would we/I do that?
The PR adding this is merged. Thanks everyone!
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.