Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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/

share|improve this question
    
Possibly relevant information: * buu700.com/tpbind * buu700.com/tpnetstat * buu700.com/tpnmap –  Ryan Lester Jan 9 '12 at 23:13
    

3 Answers 3

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=you@mail.com 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.

share|improve this answer
    
Hm, well, the chroot script already seems to bind /dev, /proc, /sys, and /tmp by default. :/ –  Ryan Lester Jan 9 '12 at 22:44

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
share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.