| From: John Jordan <[EMAIL PROTECTED]>
I'm going to assume that your problem is DNS-related.
But here's a test. When connected at the university, your normal
LINUX world is connected, but not your chrooted world, right?
Try this from your chrooted world:
ping -n 216.239.59.104
This will ping one of the google.ca IPs, without requiring DNS in any
way.
| /usr/share/fonts on /chroot/breezy/32bits/usr/share/fonts type none
| (rw,bind) [FAIL] (in red)
I don't see how this failure could relate to DNS.
| Someone asked me if I had a resolv.conf
| file in the chroot environment. I do,
| /chroot/breezy/32bits/etc/resolv.conf. Its contents are:
|
| search Comcast.net
| nameserver 216.148.227.79
| nameserver 204.127.202.19
|
| And there is another one in /etc, with the same exact contents. I
| don't know what this file does. I mention it because a local Linux
| guru asked me about it, so maybe it is significant.
Your DHCP client most likely rewrites /etc/resolv.conf to reflect what
the DHCP server told it were the DNS servers. The resolv.conf
you quote reflects what Comcast's DHCP server would have told your
client.
- the reverse DNS on these gives ns8.attbi.com. and ns9.attbi.com.
as names. I used the host(1) command to find this out.
- attbi.com is registered to AT&T but the administrative
and technical contacts are at Comcast. I used the whois(1)
command to find this out.
- the servers will not talk to me, so they probably only talk to
Comcast customers (i.e. they won't answer your computer's queries
when it is connected through the university). I used the dig(1)
command to find this out. I used TCP transport; there is a slight
chance that I would have gotten an answer if I used UDP.
If you look at /etc/resolv.conf when you are connected at the
university, it will be different. But the DHCP client doesn't know to
also change the one in your chroot universe.
What is your DHCP client? My Fedora Core 4 system uses "dhclient" but
there are others. How the plumbing for them works is different for
each.
Your simplest workaround is to copy /etc/resolv.conf to
/chrootworld/etc/resolv.conf whenever you have just connected to a
different network.
Once that works, you can think of automating this updating.
If you are using dhclient, and it is like the one on my system, the
resolv.conf is built by a script invoked by dhcpclient:
/sbin/dhclient-script. You can hack this script (either in-place, or
by telling dhcpclient to use another script). The script has a
make_resolv_conf function. It ought to be easy to slip a cp command
in there. You ought to also back up the old resolv.conf. And
reinstate it at the appropriate time (see the dhclient-script's use of
resolv.conf.predhclient).
_______________________________________________
LinuxR3000 mailing list
[email protected]
http://lists.pcxperience.com/cgi-bin/mailman/listinfo/linuxr3000
Wiki at http://prinsig.se/weekee/
