Description of problem: Rsync generates an error on every attempted operation of an otherwise normal looking config file. Version-Release number of selected component (if applicable): rsync-2.6.9-2.fc6 How reproducible: Every time Steps to Reproduce: 1. Install per rsyncd.conf below 2. /sbin/chkconfig rsync on 3. rsync localhost:: Actual results: [steve@BETHGS xinetd.d]# rsync localhost:: rsync: read error: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(604) [receiver=2.6.9] Expected results: A list of the available modules. Additional info: See attached packet capture (captured with /usr/sbin/tshark -i lo -w rsync.cap "tcp port 873"). Here is the rsyncd.conf: [home] path = /home comment = home hosts allow = 204.215.188.37, 127.0.0.1 [config] path = /etc comment = config files hosts allow = 204.215.188.37
Created attachment 151231 [details] tshark packet capture
The cap file shows just an immediate TCP reset, do you have any log file on the server side that shows what's going on?
This was rsync localhost::, so the capture includes both sides of the operation. The /var/log/messages just had: START: rsync pid=3863 from=127.0.0.1 EXIT: rsync status=1 pid=3863 duration=0(sec)
Sorry but I can't reproduce this, are you sure you don;t have any firewall rules, host allow/deny or anything else blocking? I used exactly your rsyncd.conf on a fresh install. And I get back what I should. $ rsync localhost:: home home config config files
Grr.. I rather expected that (surely I couldn't have been the first to notice a problem with rsync). However, my firewall allows all packets to/from -i lo (which is confirmed by the packet capture that shows the tcp session connecting). /etc/hosts.allow and /etc/hosts.deny contain only comments. `rpm -qV rsync` shows that the only file modified is /etc/xinetd.d/rsync (and I did that via /sbin/chkconfig so I couldn't have screwed up the config file). Just to add to the confusion, I have a four boxes that are configured via a set of scripts (so the configurations are managed and differences are well-contained). Three boxes return this error, while the fourth works as expected. I'll report back when/if I discover any differences. If you have any other ideas on where to look, I'd appreciate them.
you could run rsync (the server) under strace and see if there ... wait, have you selinux enabled by chance? :-)
I have selinux enabled on all four boxes. I'll try strace and/or disabling selinux next week.
Indeed, for some reason, /etc/rsyncd.conf was labeled correctly on one box and incorrectly (as etc_runtime_t rather than etc_t) on three of the boxes. Doing `/sbin/chkconfig /etc/rsyncd.conf` resolved the problem. How I hate the inability to synchronize the labeling of files and selinux policies, let me count the ways... Sorry for the noise.
A feature request: log the failure to open /etc/rsyncd.conf. /var/log/messages contained the startup/exit of rsyncd and I didn't think to look at /var/log/audit/audit.log. (Unfortunately, I forgot that the avc doesn't show up in /var/log/messages anymore.)
Ok I am closing this bug, please open a new one for the feature request eventually.