Servers running from chrooted Ubuntu on HP TouchPad?

Question

The problem: servers appear to be broken inside my Ubuntu chroot. No matter what kind of server I try to run, they all seem unresponsive (VLC server won't respond to client, mkRemote doesn't move the cursor, Apache gives an error about binding to port 80 and won't start, etc.).

If I'm not mistaken, what should normally happen inside a chroot is that all ports are shared between the chroot and the host, so if another machine tries to hit the host at port 80, it will still see the chrooted Web server. However, here, that isn't what's happening.

When I run netstat from the chroot, every single process lists a foreign address of 0.0.0.0:*, meaning that the only machine which can act as a client is the local host. This is clearly incorrect and abnormal behaviour, as any process on my primary machine meant to be publicly visible lists a foreign address of :::* (which I assume means that any client can see it from any port).
Edit: Disregard that; apparently the foreign address only distinguishes between whether it's listening for IPv4 or IPv6 connections, so it doesn't seem relevant here.

So far, Googling has returned nothing of value, and I'm basically stumped. Any ideas? Could it just be some setting which one of the chroot patch devs enabled by default, or does it seem like a more complicated issue?

Thanks.

More context: http://rootzwiki.com/topic/14682-webos-servers-inside-chrooted-ubuntu/

Answer 1

I'm running a boinc service inside a chrooted debian. I use this script to chroot (argument 1 is the location, like /media/debian)

#!/bin/sh
mount --bind /dev $1/dev
mount --bind /proc $1/proc
mount --bind /sys $1/sys
[email protected] LANG=C HOME=/root chroot $1
umount $1/dev
umount $1/proc
umount $1/sys

Rerouting proc and sys is necessary in order to reuse network devices. It also works for apt-get dist-upgradeing the otherwise dual booted debian or yum upgradeing a dual booted fedora.

Answer 2

Try issuing the following commands outside of the chroot. I had to issue these before I could access anything being served from within the chroot, and still have to issue them every time.

iptables -F
iptables -P INPUT ACCEPT
iptables -X ALLOWED_PACKETS
iptables -X ICMPFLOOD
iptables -X INVALID_PACKETS

Answer 3

People of the future, do not fear. If you've found this question, you've come across a frustrating problem and are looking for a sure-fire solution. Luckily, I have answered this question on a different SE site. It has worked for both the OP and me. It can be found here.