HTTP encapsulated rsync??
Hi folks, I am hoping someone here can offer some suggestions. Here is my situation: I am using rsync over the internet for several hundred clients to keep them in sync with a master repository of files. The rsync daemon is listening on port 80, because most of the clients are behind firewalls that only allow outbound port 80 (and other common ports). This works fine for most of them but not all. The trouble is that some of them are also behind devices that do not allow non-http traffic on port 80 and thus block the rsync. Therefore, I am looking for a way to use http encapsulation as a means to bypass the blocking devices. I have seen a few scattered queries around the net asking similar questions but I have not seen any good solutions offered. One person suggested that http-tunnel be used but this is not a very elegant solution and I would like to avoid it if at all possible. If the tunnel were to hang or sever then I would have a difficult time correcting it since I do not have direct access to many of the clients. Does anyone here have any ideas? Surely I am not the first person to ask this question. Thanks!! Robert -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: HTTP encapsulated rsync??
On 4/17/07, Robert Denton [EMAIL PROTECTED] wrote: Hi folks, I am hoping someone here can offer some suggestions. Here is my situation: I am using rsync over the internet for several hundred clients to keep them in sync with a master repository of files. The rsync daemon is listening on port 80, because most of the clients are behind firewalls that only allow outbound port 80 (and other common ports). This works fine for most of them but not all. The trouble is that some of them are also behind devices that do not allow non-http traffic on port 80 and thus block the rsync. Therefore, I am looking for a way to use http encapsulation as a means to bypass the blocking devices. I have seen a few scattered queries around the net asking similar questions but I have not seen any good solutions offered. One person suggested that http-tunnel be used but this is not a very elegant solution and I would like to avoid it if at all possible. If the tunnel were to hang or sever then I would have a difficult time correcting it since I do not have direct access to many of the clients. Does anyone here have any ideas? Surely I am not the first person to ask this question. Thanks!! Robert You can use an HTTP proxy. Look at the RSYNC_PROXY environment variable in the man page. -- Aaron W Morris (decep) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: HTTP encapsulated rsync??
Do you mean for example.. Instead of running rsync on port 80, have rsync listen for requests on 873 as usual, but also have squid running on the same server listening for port 80 connections, and then just configure squid to send all port 80 traffic to 873? Robert On Apr 17, 2007, at 1:27 PM, Aaron W Morris wrote: On 4/17/07, Robert Denton [EMAIL PROTECTED] wrote: Hi folks, I am hoping someone here can offer some suggestions. Here is my situation: I am using rsync over the internet for several hundred clients to keep them in sync with a master repository of files. The rsync daemon is listening on port 80, because most of the clients are behind firewalls that only allow outbound port 80 (and other common ports). This works fine for most of them but not all. The trouble is that some of them are also behind devices that do not allow non-http traffic on port 80 and thus block the rsync. Therefore, I am looking for a way to use http encapsulation as a means to bypass the blocking devices. I have seen a few scattered queries around the net asking similar questions but I have not seen any good solutions offered. One person suggested that http-tunnel be used but this is not a very elegant solution and I would like to avoid it if at all possible. If the tunnel were to hang or sever then I would have a difficult time correcting it since I do not have direct access to many of the clients. Does anyone here have any ideas? Surely I am not the first person to ask this question. Thanks!! Robert You can use an HTTP proxy. Look at the RSYNC_PROXY environment variable in the man page. -- Aaron W Morris (decep) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: HTTP encapsulated rsync??
On 4/17/07, Robert Denton [EMAIL PROTECTED] wrote: Do you mean for example.. Instead of running rsync on port 80, have rsync listen for requests on 873 as usual, but also have squid running on the same server listening for port 80 connections, and then just configure squid to send all port 80 traffic to 873? Robert I was thinking more along the lines of creating a proxy for all of your rsync requests. You would not necessarily have to do any special configuration to squid (except allow CONNECT with port 873, something I know has to be done with mod_proxy), it should route the request itself. Apache with mod_proxy would work as well. -- Aaron W Morris (decep) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: HTTP encapsulated rsync??
This is an interesting idea. Here is what I am trying: I have set up squid to listen on port 81, since rsync on the same machine is already listening for requests on 80. I have set the RSYNC_PROXY env var to the hostname:81 and rand a quick test. The result is that I am getting this error: bad response from proxy -- HTTP/1.0 503 Service Unavailable rsync: failed to connect to 192.168.233.56: Success (0) I am thinking this is a problem with the squid config not passing the rsync request to the rsync daemon. Another though occurs to me: many of the clients are behind enforced proxies of their own, set via an env var: http_proxy. Is this going to work with the RSYNC_PROXY? Since the rsync proxy is pointing to an http port on a server, will the request automatically be channeled through the enforced http_proxy? Robert On Apr 17, 2007, at 4:00 PM, Aaron W Morris wrote: On 4/17/07, Robert Denton [EMAIL PROTECTED] wrote: Do you mean for example.. Instead of running rsync on port 80, have rsync listen for requests on 873 as usual, but also have squid running on the same server listening for port 80 connections, and then just configure squid to send all port 80 traffic to 873? Robert I was thinking more along the lines of creating a proxy for all of your rsync requests. You would not necessarily have to do any special configuration to squid (except allow CONNECT with port 873, something I know has to be done with mod_proxy), it should route the request itself. Apache with mod_proxy would work as well. -- Aaron W Morris (decep) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: HTTP encapsulated rsync??
On 4/17/07, Robert Denton [EMAIL PROTECTED] wrote: This is an interesting idea. Here is what I am trying: I have set up squid to listen on port 81, since rsync on the same machine is already listening for requests on 80. I have set the RSYNC_PROXY env var to the hostname:81 and rand a quick test. The result is that I am getting this error: bad response from proxy -- HTTP/1.0 503 Service Unavailable rsync: failed to connect to 192.168.233.56: Success (0) I am thinking this is a problem with the squid config not passing the rsync request to the rsync daemon. Another though occurs to me: many of the clients are behind enforced proxies of their own, set via an env var: http_proxy. Is this going to work with the RSYNC_PROXY? Since the rsync proxy is pointing to an http port on a server, will the request automatically be channeled through the enforced http_proxy? Robert If some of the clients are already having to go through proxies, it does complicate matters. If that is the case, you may have to investigate setting up said proxies to proxy again using proxy chaining/cascading, but that's a bit out of scope for this mailing list. It's difficult for me to say what the problem is with the 503 error, but it sounds like you're on the right track. -- Aaron W Morris (decep) -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
