deajan
Default shell for remote user is expected to be bash
There is an example in documentation, which shows how to invoke osync when bash is not the default shell. It would be helpful to put there also note which mentions that bash as default shell is also expected from remote ssh user.
When remote users default shell is for example tcsh and bash is installed, then osync fails with unhelpful messages:
TIME: 1 - Creating target replica file list [/usr/home/user/dest/]. TIME: 1 - Cannot create replica file list in [/usr/home/user/dest/]. TIME: 1 - Truncated output: env: No match. rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.3] TIME: 1 - _ExecTasksPidsCheck called by [Sync_treeListBefore] finished monitoring pid [17603] with exitcode [12]. TIME: 2 - osync finished with errors.
After replacing remote users default shell with bash, osync runs without errors.
Does this requirement means that osync can not be used with service providers which do not allow direct log in? rsync.net for example supports rsync, but there is no interactive session.
Indeed, for osync logic to work, an ssh login is mandatory. I'll add something to the doc, but since osync won't be able to detect the remote shell it connects to, I cannot make a valid error message.
Are there workarounds for cases when ssh target doesn't allow interactive session?
For example, what may be the possible shortcomings of the following algorithm in case of local ZFS file system:
- Create snapshot from local dataset.
- Create clone from snapshot.
- rsync remote ssh target to clone.
- zfs diff clone and snapshot. If diff is empty then destroy clone and snapshot. Done.
- osync locally with clone.
- rsync clone back to ssh target.
- destroy clone and snapshot.
Sorry, osync needs to transfer some code remotely in order to be able to deal with file attributes and deletions. No interactive session means no sync possibility.