`rsync`: `sshUser` hard-coded to `root`.

[reitermarkus]

Describe the bug

It seems like the sshUser doesn't do anything when using a ReplicationSource with rsync, since the user is hard-coded to root here:

https://github.com/backube/volsync/blob/26262aaec82d05c1a092cc6989bd798af1fb617e/mover-rsync/source.sh#L71

Also, it seems like the rsync mover will shut down the target after the sync:

https://github.com/backube/volsync/blob/26262aaec82d05c1a092cc6989bd798af1fb617e/mover-rsync/source.sh#L85

I am trying to back up a large volume to a local NAS (i.e. not a second Kubernetes cluster) which obviously should not be shut down after a backup.

Steps to reproduce

Create a ReplicationSource with an sshUser other than root.

Expected behavior

The mover container connects with the user specified by sshUser.

Actual results

The mover container connects with the user root.

Additional context

[JohnStrunk]

root being hardcoded is definitely a bug. We provide the option to configure the user in the CR but we clearly don't pass it through.

About the "shutdown" call... The rsync mover isn't designed to connect to a non-volsync destination. In the (destination) mover pod, we configure sshd such that it doesn't actually invoke the command from the ssh call. See: https://github.com/backube/volsync/blob/56194a2e1e8a9bec86462be730a4c6c30e8725b2/mover-rsync/destination.sh#L10 This ensures that every call ends up going through the destination-command.sh script, and that interprets the shutdown command.

For your use-case, the rclone or restic movers may be better choices. Restic would be good if you're just trying to make a backup. Rclone could (probably) be used to mirror the files if that's what you want.