Martin,
Thanks for your insights. I was able to create an openssl
version of rsync for Windows and Linux. It did take more
coding as you mentioned, but it seems quite stable and speedy. The
reason
for this undertaking was to create a version of rsync that could
communicate with the Netware port, which doesn't use ssh because
of a lack of a ssh on shipping versions. It also could be useful
in a embedded environment, but I may be grasping at straws. In any
case, thanks for the help.
Lee
>>> Martin Pool <mbp@samba.org> 6/18/2003 5:17:03 AM >>>
On 20 Feb 2003, Lee Wiltbank <lwiltbank@novell.com> wrote:
> I have been working on a project to Openssl'ify Rsync. I am having
> problems when Rsync forks two processes to handle a sender and was
> wondering if anyone else would be able to lend a hand or some
> pointers. I have posted to mailing.openssl.dev
>
> Basically, I have brought up Rsync 2.5.5 on cygwin. It goes through
> the Openssl init and then waits on accept. When it accepts, it
forks> itself. The child then communicates with the other side. The
problem> occurs when Rsync determines that it is the receiver and forks
itself> again. Then there are two processes with the same SSL object. I
> am having a lot of trouble getting data from the client once Rsync
> does this two-fork thing. I know that Openssl is multi-thread
> capable, but this situation is where two processes have the same
> SSL object and attached socket and are working with it.
>
> This version works fine when Rsync is the sender, that is, the
client> connects and the server sends the files over. In this case, there
is> only one process trying to write to the SSL object and socket.
There are a few difficult historical facts, as you say
- Forking on the receiver is pretty tightly embedded into the
application and protocol.
- OpenSSL just cannot handle a single socket being used from two
different processes. Unlike with threads, it does not have any
easy place to keep common state. And in any case the two processes
assume they can just do their own thing; I'm not sure they would be
able to synchronize in the way required by SSL.
Consider that a "write" operation from the applications point of
view may result in several reads and writes in the SSL layer, and
vice versa.
None of these issues are absolutely insurmountable (it's just code)
but they are pretty tough. My recommendation is not to waste your
time.
Therefore one might look at putting SSL in a separate process that
stands between the real socket and rsync. You could fork this off
just before starting processing, perhaps in response to a command line
parameter.
Or you could just use stunnel, which does essentially this only with a
bit more manual setup.
SSH already works and is at least as easy to set up as SSL. (Key
management is far more practical.) Is SSH not available on Netware,
or are there issues with it?
--
Martin
