You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Syncoid makes SSH connections local->remote, even if the direction of sync is remote->local. The --insecure-direct-connection option instead makes TCP connections source->target. This can be a problem if, for example, you want to restore a dataset from an untrusted backup host that's not allowed to make connections to the target through a firewall.
Some options for fixing this:
Add an option that sets the direction of connection to target->source.
Add an option that sets the direction of connection to local->remote, regardless of which one is the target.
Make local->remote the default, for parity with the SSH connection.
I lean toward (3), although I could see existing users wanting an option to revert to the current source->target scheme.
Both socat and nc support sending piped input across incoming TCP connections. It looks like mbuffer does not.
I'm happy to spin up a PR if the concept seems sound.
As an aside, is there a reason socat is used to send, while either mbuffer or nc (but not socat) is used to receive? It seems like most combinations are possible in principle, with the notable exception that mbuffer cannot listen on the send side (or initiate the connection from the receive side).
The text was updated successfully, but these errors were encountered:
Syncoid makes SSH connections local->remote, even if the direction of sync is remote->local. The
--insecure-direct-connection
option instead makes TCP connections source->target. This can be a problem if, for example, you want to restore a dataset from an untrusted backup host that's not allowed to make connections to the target through a firewall.Some options for fixing this:
I lean toward (3), although I could see existing users wanting an option to revert to the current source->target scheme.
Both
socat
andnc
support sending piped input across incoming TCP connections. It looks likembuffer
does not.I'm happy to spin up a PR if the concept seems sound.
As an aside, is there a reason
socat
is used to send, while eithermbuffer
ornc
(but notsocat
) is used to receive? It seems like most combinations are possible in principle, with the notable exception thatmbuffer
cannot listen on the send side (or initiate the connection from the receive side).The text was updated successfully, but these errors were encountered: