iconv and daemon mode

[Jochen Reinwand]

Just to give some positive feedback:
The problem was indeed the chroot of rsyncd! Since I'm only using rsyncd in my 
internal LAN and I'm only starting it on demand, it's no problem for me to 
disable chroot for the time being.
Thanks for the help!

Jochen

On Saturday 09 February 2008 23:41, Matt McCutchen wrote:
> On Sat, 2008-02-09 at 23:11 +0100, Jochen Reinwand wrote:
> > On Saturday 09 February 2008 22:39, Matt McCutchen wrote:
> > > On Sat, 2008-02-02 at 14:00 +0100, Jochen Reinwand wrote:
> > > > iconv_open("UTF-8", "iso8859-15") failed
> > > > rsync error: requested action not supported (code 4) at rsync.c(120)
> > > > [receiver=3.0.0pre8]
> >
> > I already thought about that, but everything seems to work fine. I
> > created a file with some umlauts in UTF-8 and converted it:
> >
> > $ iconv -f UTF-8 -t iso8859-15 -o test-iso-8859-15 test-utf8
> >
> > No error message.
>
> I asked myself how iconv could possibly work at the command line and for
> an rsync client but not for an rsync daemon, and I figured out what is
> going on.  If the module uses chroot, that prevents iconv_open from
> accessing the necessary encoding helper library.  (Unpleasant echoes of
> the log timezone nonsense.)
>
> This would be nontrivial to fix: in order to setup iconv before
> chrooting, the daemon would have to parse its arguments (to see the
> --iconv option) before chrooting, which could have consequences for
> security checking of paths that I don't care to hash through.  Instead,
> let's recommend daemon administrators to copy the necessary encoding
> helper libraries into the module and daemon-exclude them.  (On my
> computer, that would be the /usr/lib/gconv dir.)  I'll propose a patch
> that adds a note about this to the description of "use chroot" in the
> rsyncd.conf(5) man page.
>
> Matt