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):
Steps to Reproduce:
1. Install per rsyncd.conf below
2. /sbin/chkconfig rsync on
3. rsync localhost::
[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)
A list of the available modules.
See attached packet capture (captured with /usr/sbin/tshark -i lo -w rsync.cap
"tcp port 873").
Here is the rsyncd.conf:
path = /home
comment = home
hosts allow = 22.214.171.124, 127.0.0.1
path = /etc
comment = config files
hosts allow = 126.96.36.199
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::
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.