I'm seeing from various past mailing list exchanges that rsync is the
suggested course of action for copying a bunch of files.
However, this doesn't seem to really work for deploying files
throughout the filesystem in places that require root (e.g. various
files under /etc). We (as I imagine is a common config) don't have
direct root ssh logins, so simply following what's suggested in the
docs doesn't work:
local_action: command rsync -rlp common/files
{{ansible_ssh_user}}@{{inventory_host}}
Any other good approach here? Ideally something that can additionally
set appropriate ownership of the files after copying the data?
Thanks.
(We can just go back to tar-ing all the files over ssh, although if we
keep up with our ansible hacks like this we seem to just be reverting
to what our original shell scripts were doing, so we're wondering if
we're missing anything.)
Since you can’t rsync to root locations and need to, a super easy way to do it is to check your content into git and use the git module to redeploy it (or SVN, etc).
Maybe we need two modules, e.g. inflate and deflate, the first creates a tar (delegated if need be) and the second would extract the tar (delegated if need be). Combining these two would allow you to inflate anywhere, and deflate anywhere exactly what you like. It could be one-to-many, or many-to-one, or even many-to-many exactly as you need.
Of course rsync is more versatile in keeping it 'idempotent', but I guess the inflate/deflate modules are very generic, versatile building blocks to do whatever you fancy doing. Even outside of the scope of what rsync does.
So inflate is tar, and deflate is tar.
Like the abstraction but curious to what they would do to make them interesting as modules.
(Devil’s advocate mode, I guess.)
Maybe it can be a little bit different that simple tar/tar.
We can have servers without direct connection
localhost -> A
localhost -> B
A <- NOT -> B
inflate: create tar and copy data on localhost
deflate: copy tar from localhost to remote server
(this can be required ONLY when direct connection from servers is not
available, maybe a module parameter)
Another "goodies" can be that tar con just override file, but it don't
check if a file is changed or not, so we can't use "notify" on action.
Checking for files already seems well served by ‘copy’, just make the copy task notify, etc.
Retrieval would be via “fetch”.
Sure, we can have a "roles" that merge all task and make a simulated
"rsync" (fetch + copy)..