More fun to be had debugging! Rsync and xinetd - those two old friends - are not playing ball, and there error is not something I've ever seen before.
So if you have an F9 machine and want to debug something (and hopefully help craft a patch).
To start, add a repo to your F9 box pointing to http://fedora.laptop.org/xs/testing/olpc/7/i386 - keep it disabled by default - I don't want a yum update to switch your desktop machine into a school server. Not yet at least.
Notes: - that repo contains a single dangerous package. Do NOT dare install xs-config - it will reconfigure your machine in unexpected ways. Everything else is pretty sane. - even if harmless, the packages here will create a directory called /library - assuming you don't have a /library dir you use, all is safe...
1 - From that repo, install xs-rsync, most dependencies are harmless, (see cleanup notes later).
2 - xs-rsync by default binds to an odd address, edit the bind address in /etc/xinet.d/xs-rsync so that it listens on localhost
3 - ah, magic moment: run `rsync rsync://localhost/` - normally, it should list one directory: 'builds' (this is from /library/xs-rsync/pub feel free to put something there).
On my system, it errors out, and /var/log/messages talks about getpeeraddr errors, which I've never seen before. Nor has google :-/
4 - ???
5 - patch!
Cleanup:
- You will probably want to remove xinetd, incron, and usbmount if you are not otherwise using them.
- rm /library if there is no content of yours there.
cheers,
m
On Sat, Aug 30, 2008 at 2:46 AM, Martin Langhoff martin.langhoff@gmail.com wrote:
More fun to be had debugging! Rsync and xinetd - those two old friends
- are not playing ball, and there error is not something I've ever
seen before. [...]
Well, it looks like fakechroot is the culprit, fwiw. If I take your configs and remove the fakechroot bit from the serverargs line:
server_args = -i /library/xs-rsync/state/rsyncd.all -- /usr/bin/rsync --daemon --config /etc/xs-rsyncd.conf
It works fine.
I dunno anything much about fakechroot, though.
-RN
Argh, forgot replytoall again.
On Sat, Aug 30, 2008 at 12:07 PM, Robin Norwood robin.norwood@gmail.com wrote:
On Sat, Aug 30, 2008 at 2:46 AM, Martin Langhoff martin.langhoff@gmail.com wrote:
More fun to be had debugging! Rsync and xinetd - those two old friends
- are not playing ball, and there error is not something I've ever
seen before. [...]
Well, it looks like fakechroot is the culprit, fwiw. If I take your configs and remove the fakechroot bit from the serverargs line:
server_args = -i /library/xs-rsync/state/rsyncd.all --
/usr/bin/rsync --daemon --config /etc/xs-rsyncd.conf
It works fine.
I dunno anything much about fakechroot, though.
Though I notice that rsync does some strange business to figure out the right args for getpeername() in configure.sh, and fakechroot seems to have it's own version of getpeername, et. al. so it's probably that getpeername from fakechroot uses different args than the system getpeername.
And now I'm curious, so I'll poke around some more while the kids play Lego Indiana Jones.
-RN
On Sat, Aug 30, 2008 at 12:12 PM, Robin Norwood robin.norwood@gmail.com wrote:
Though I notice that rsync does some strange business to figure out the right args for getpeername() in configure.sh, and fakechroot seems to have it's own version of getpeername, et. al. so it's probably that getpeername from fakechroot uses different args than the system getpeername.
Yeah, I can confirm that fakechroot's getpeername() is the problem. If I remove getpeername from fakechroot [1], then I get a fakechroot that works with your test [2]. Obviously we need to instead sort out the parameters to match the system getpeername like rsync does. Not really my area of expertise, but I can file a bug in RH bugzilla for fakechroot when I get back. Got to run, now.
[1] http://rnorwood.fedorapeople.org/robin-fakechroot.patch [2] http://rnorwood.fedorapeople.org/fakechroot-2.8-13.fc9.2.i386.rpm
-RN
On Sat, Aug 30, 2008 at 12:28 PM, Robin Norwood robin.norwood@gmail.com wrote:
On Sat, Aug 30, 2008 at 12:12 PM, Robin Norwood robin.norwood@gmail.com wrote: Yeah, I can confirm that fakechroot's getpeername() is the problem. If I remove getpeername from fakechroot [1], then I get a fakechroot that works with your test [2]. Obviously we need to instead sort out the parameters to match the system getpeername like rsync does. Not really my area of expertise, but I can file a bug in RH bugzilla for fakechroot when I get back. Got to run, now.
Me again:
https://bugzilla.redhat.com/show_bug.cgi?id=460753
Thanks,
-RN
On Sun, Aug 31, 2008 at 4:28 AM, Robin Norwood robin.norwood@gmail.com wrote:
Yeah, I can confirm that fakechroot's getpeername() is the problem. If I remove getpeername from fakechroot [1], then I get a fakechroot that works with your test [2]. Obviously we need to instead sort out the parameters to match the system getpeername like rsync does. Not really my area of expertise, but I can file a bug in RH bugzilla for fakechroot when I get back. Got to run, now.
Thanks! From what I see in your patch, you're working around the problem by removing the local implementation of getpeername() so yes, I agree we'll want to see what upstream says about a proper fix.
I'm not versed in the semantics of getpeername() so can't suggest anything smart at the moment.
In the meantime, I'll use your package for testing and try to find out how serious it is that getpeername() gets through unwrapped.
Thanks again!
m
On Sun, Aug 31, 2008 at 5:39 PM, Martin Langhoff martin.langhoff@gmail.com wrote:
On Sun, Aug 31, 2008 at 4:28 AM, Robin Norwood robin.norwood@gmail.com wrote:
Yeah, I can confirm that fakechroot's getpeername() is the problem. If I remove getpeername from fakechroot [1], then I get a fakechroot that works with your test [2]. Obviously we need to instead sort out the parameters to match the system getpeername like rsync does. Not really my area of expertise, but I can file a bug in RH bugzilla for fakechroot when I get back. Got to run, now.
Thanks! From what I see in your patch, you're working around the problem by removing the local implementation of getpeername() so yes, I agree we'll want to see what upstream says about a proper fix.
I'm not versed in the semantics of getpeername() so can't suggest anything smart at the moment.
In the meantime, I'll use your package for testing and try to find out how serious it is that getpeername() gets through unwrapped.
Check the bug again, Axel added what I think is the correct fix. He's waiting of a response from upstream, but we should have the fix soon.
https://bugzilla.redhat.com/show_bug.cgi?id=460753
http://rnorwood.fedorapeople.org/fakechroot-2.8-13.fc9.4.i386.rpm
Is the one I built with Axel's patch, and it seems to work fine for me. Note that I bumped the release to the right of the dist tag, so when axel released -14 (or whatever), upgrades should work.
-RN
On Mon, Sep 1, 2008 at 10:59 AM, Robin Norwood robin.norwood@gmail.com wrote:
Check the bug again, Axel added what I think is the correct fix. He's waiting of a response from upstream, but we should have the fix soon.
Yep, just got a gentle prod from Axel in private too :-) His patch looks good, and your comment about getsockname() is also interesting.
http://rnorwood.fedorapeople.org/fakechroot-2.8-13.fc9.4.i386.rpm
Is the one I built with Axel's patch, and it seems to work fine for me. Note that I bumped the release to the right of the dist tag, so when axel released -14 (or whatever), upgrades should work.
Cool. I'll use it for internal testing, and hope that upstream replies and Fedora updates get untagled before the next XS release :-)
This is great. A few more pushes to the networking side, and we'll have a ported XS.
m