Behaviour that I don't understand

[Alan Chandler]

Paul Slootman writes: 

> On Wed 02 Aug 2006, Alan Chandler wrote: 
> 
>> The /etc/rsyncd.conf file has the following in it  
>> 
>> chroot = false 
>> strict modes = false
>> hosts allow = 192.168.0.0/24 127.0.0.1 
>> 
>> [system]
>> path = /cygdrive/c
>> comment = the complete c drive 
>> 
>> 
>> [alan]
>> path = /cygdrive/c/Documents and Settings/ChandlerA
>> comment = Alan's specific user space
> [...] 
> 
>> HOWEVER 
>> 
>> If I try to list the contents of either module from local host (thus) 
>> 
>> rsync localhost::system 
>> 
>> it works, but if I list the contents via 
>> 
>> rsync rabbit::system
>> (either remotely or locally) 
>> 
>> then I get  
>> 
>> @ERROR: access denied to system from roo.home (192.168.0.20)
> 
> Try putting the hosts allow line in the modules definition; the man page
> does say:
>     You may also include any module parameters in the global  part  of  the
>     config  file in which case the supplied value will override the default
>     for that parameter.
> However maybe there's some bug :-)

Its a bit hard because I am at work rather than home, so not with the same 
IP addresses.  Nevertheless I can simulate the effect by setting the work IP 
address in rsyncd.conf and connecting from the same machine. 

Moving the hosts allow into the module does not effect things EXCEPT that
I didn't include localhost in my host allow statements, but that still 
works. 

> 
> BTW: you don't mention what version you're using.

Its 2.6.6 (Protocol 29) under cygwin for the machine running the daemon 

I am using itself as one client (test above), and when at home I am running 
from Debian Sarge - which is 2.6.4 (Protocol 29). 

I DO now have a work around that works - ie list the individual IP addresses 
of the machines I want to allow to connect, rather than a range 

ie 

hosts allow = 192.168.0.20 192.168.0.21 

rather than 

hosts allow = 192.168.0.0/24 

The second form DOES seems to work on my other machines (all under linux as 
opposed to this machine using cygwin) AND I had the exact same configuration 
working on my old laptop (running Windows 2000 professional) which just 
stopped working when I got a new work laptop with Windows XP and I 
transfered the configuration across. When I first raised this I hadn't 
narrowed the problem down enough to find a work around - so I was looking 
for answers.  Now I suspect some bug with the cygwin implementation, and I 
would just like to help out to see that it can get fixed if that is indeed 
the case, or understand what I am doing wrong if it is not. 

 


 --
Alan Chandler
alan at chandlerfamily.org.uk