rsyncd.conf behavior

10 posts / 0 new
Last post
itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
rsyncd.conf behavior

Rsync has been running for some time without any problem. The server is Windows Server 2003 and the clients are also Windows OS. All of my clients are working except one. In troubleshooting, I worked on the problem-child but got no where. So, I went to a working client and tried to change the behavior of that client to get a better idea if the problem is with the problem-child or my server. Well, I can't change the behavior of the one that is working. Here is part of my rsyncd.conf.
****************** rsyncd.conf*****************
use chroot = false
strict modes = false
hosts allow = *
log file = rsyncd.log
pid file = rsyncd.pid

hosts allow = 192.168.1.0/24, 5.6.7.8
path = d:/customers/clienta
read only = no
list = no

hosts allow = 192.168.1.0/24, 1.2.3.4
path = d:/customers/clientbRemoteBackup
read only = no
list = no
****************** rsyncd.conf*****************

ClientB is the one that is the problem. 1.2.3.4 is a representation of a public ip address. From ClientB's computers I try "telnet rsyncserver.mydomain.com 873". But if I go to ClientA's computer and try "telnet rsyncserver.mydomain.com 873", I get through with the message " @RSYNCD: 28
@ERROR: protocol startup error"
So, as a test, I changed the ip address on the working client to see if I could make it fail and I couldn't.
Here's what I changed it to...notice I changed the last octet of the ip address in the hosts allow line. That should've caused the telnet to fail but it didn't. I even restarted the rsync service just in case. I know you don't have to do that but I wanted to make sure.

hosts allow = 192.168.1.0/24, 5.6.7.9
path = d:/customers/clienta
read only = no
list = no

I even removed the clienta module from the file and clienta could still connect. I thought maybe there was another rsyncd.conf file stuck somewhere that I didn't know about...there isn't.

So, it seems that the problem is with my server and not the clients but I just can't seem to get to the bottom of this.

thanks for your help,
Mike

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

From the protocol number 28, I assume that you run an older rsync (29 as of rsync 2.6.4). If that means you run a cwrsync version older than 1.3.0, existence of an rsync service bug may explain this odd behaviour. This bug avoids rsync service to stop rsync daemon itself. If you start the service several times, you might end up with several rsync daemon instances on your machine.
If this is the case, I recommend upgrading cwrysnc. Nowadays, I wait for the official release of rsync 2.6.5. I will then publish a new installer with many new features.

Rgrds Tev

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

Thanks for the reply...
Starting and stopping the rsync service does not produce more running services.

I guess my only chance at this point is to reinstall

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

Have you tried to increase log verbosity at server side ? It might help to pinpoint the problem.

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

Ok...I downloaded the newest version of cwrsync and reinstalled. I removed the old version first, saving my rsyncd.conf file. The same behavior is occuring as with the old version. Please read my first posting to get a description of the behavior.
The last posting asked that I increase verbose logging on the server-side. I did a little research and don't see how to do that. In the interest of time, can someone tell me how to do that and what log I should be looking at in the c:\program files\cwrsync folder?

Thanks,
Mike

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

Forget about verbose logging at server side. Switch -vvv simply doesn't work. You wrote :
-------
ClientB is the one that is the problem. 1.2.3.4 is a representation of a public ip address. From ClientB's computers I try "telnet rsyncserver.mydomain.com 873". But if I go to ClientA's computer and try "telnet rsyncserver.mydomain.com 873", I get through with the message " @RSYNCD: 28 @ERROR: protocol startup error"
-------
A dumb question :

Telnet 873 from ClientA seems to work as you get an answer. I assume that you don't get answer when you try from ClientB. Could it be some blocking problem somewhere in the pipe (firewall, proxy server ...) ?

Rgrds Tev

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

I considered a firewall issue before I started any further troubleshooting and ruled that out very quickly. There is nothing blocking outbound traffic on the firewall. So, I expanded the search for a blocking problem by going to another customer who is using the same ISP. That's when I discovered that I could not change anything in the rsyncd.conf file to block that customer. Let's call the one that I'm having connection problems with, ProblemChild and the one that uses the same ISP and has no connection problems, GoodChild. In an effort to gain understanding of what might be happenning, I modified rsyncd.conf for GoodChild in an effort to make that connection fail. So, I changed the "hosts allow = 192.168.1.0/24, 1.2.3.4" so that the 1.2.3.4 was 1.2.3.5 so this connection would fail. GoodChild still connected. So, that seems to tell me something must be wrong with my server configuration. I still may have a problem with the connection for ProblemChild. But, I think I also have a problem on the server. So, I thought I'd deal with the server first in hopes that might fixe ProblemChild too. But, if it doesn't then I will deal with ProblemChild afterwards.
I hope this makes sense.

Mike

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

I tried something else. I set up a new customer adding the following lines to rsyncd.conf.

hosts allow = 192.168.1.0/24, 208.188.105.138
path = d:/customers/sprhs
read only = no
list = no

It didn't work...I could not connect to my rsync server using telnet to port 873.

Mike

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

Do you have multiple network cards on your server ?

itefix
Offline
Last seen: 1 week 6 days ago
Joined: 01.05.2008 - 21:33
Re: rsyncd.conf behavior

no...only one network card.

Topic locked

Release announcements