I'm running FC4, and last night I was reading about NetworkManager, and I realized I never tried it. So I do: $ su # /etc/init.d/NetworkManager start
It started alright, but everything (network) stopped working! BTW, this is happening on a desktop with only a wired eth0.
I say 'F@#% it!' and I stop it quickly, but the network is still down. I bounce eth0 once: # ifdown eth0 # ifup eth0 Still no go. After a while I figure out that pings are working, but DNS is foo-bared. Sure enough, NetworkManager completely erased my /etc/resolv.conf! Needless to say, my resolv.conf was 100% hand-edited with search and nameserver entries that NetworkManager can not possibly guess. Why did it feel the need to mess with it?
Now, apart from the very frustrating experience, is this intended behavior? If so, does it really have to be this way?
Now, apart from the very frustrating experience, is this intended behavior? If so, does it really have to be this way?
Yes its intended behaviour. Networkmanager at the moment works with dhcp only its intended more for laptops where you will be using many different networks. it makes it easy to change. and different networks have different requirements. one thing that would be a nice addon. is if the dhcp server gives out a proxy server it setsup iptables rules to forward all traffic to port 80 and 21 to the proxy server. so you never need to configure browsers, etc
Dennis
On Thu, 2005-07-14 at 08:19 -0500, Dennis Gilmore wrote:
Now, apart from the very frustrating experience, is this intended behavior? If so, does it really have to be this way?
Yes its intended behaviour. Networkmanager at the moment works with dhcp only its intended more for laptops where you will be using many different networks. it makes it easy to change. and different networks have different requirements. one thing that would be a nice addon. is if the dhcp server gives out a proxy server it setsup iptables rules to forward all traffic to port 80 and 21 to the proxy server. so you never need to configure browsers, etc
It does work with any static IP address you have configured with system-config-network. It will apply the IP & DNS configuration you've selected using system-config-network Profiles on startup. NM blows away your /etc/resolv.conf because it uses a local caching nameserver to deal with horrible glibc resolver dropouts when network switches occur. That's not likely to change, what may change would be the ability to add custom entries to the caching nameserver's config.
Dan
Dan Williams wrote:
It does work with any static IP address you have configured with system-config-network. It will apply the IP & DNS configuration you've selected using system-config-network Profiles on startup. NM blows away your /etc/resolv.conf because it uses a local caching nameserver to deal with horrible glibc resolver dropouts when network switches occur. That's not likely to change, what may change would be the ability to add custom entries to the caching nameserver's config.
Dan
My Bad, i havent had anything in system-config-network for along time. ill have to try it out.
Dennis
On Thu, 2005-07-14 at 10:16 -0400, Dan Williams wrote:
NM blows away your /etc/resolv.conf because it uses a local caching nameserver to deal with horrible glibc resolver dropouts when network switches occur. That's not likely to change, what may change would be the ability to add custom entries to the caching nameserver's config.
Dan
It should be optional - I can't use it for that reason. It needs to use the nameserver specified by the dhcp server or I can't use it.
On Thu, 2005-07-14 at 17:40 -0700, Michael A. Peters wrote:
It should be optional - I can't use it for that reason. It needs to use the nameserver specified by the dhcp server or I can't use it.
Won't the local caching name server look to that DHCP provided DNS server for "upstream" dns info?
On Thu, 14 Jul 2005, Jesse Keating wrote:
On Thu, 2005-07-14 at 17:40 -0700, Michael A. Peters wrote:
It should be optional - I can't use it for that reason. It needs to use the nameserver specified by the dhcp server or I can't use it.
Won't the local caching name server look to that DHCP provided DNS server for "upstream" dns info?
Exactly, NetworkManager gets the DNS server addresses via DHCP, then writes them to the caching-nameserver's config file. So your local machine always talks to 127.0.0.1, but the caching-nameserver talks to yhe real DNS servers.
Dan
On Thursday 14 July 2005 22:16, Dan Williams wrote:
NM blows away your /etc/resolv.conf because it uses a local caching nameserver to deal with horrible glibc resolver dropouts when network switches occur. That's not likely to change, what may change would be the ability to add custom entries to the caching nameserver's config.
I don't use NM yet, but I also use local DNS as well to get around this problem and also to add another very nice feature: Union two domains together. You can't do this with resolver. Each nameserver in /etc/resolv.conf needs to be a complete set that are identical to other. It will not say, "hey I can't find foo in nameserver 1, so let me go find it in nameserver 2."
However, local DNS, can say, "hey foo is in bar.com, so i'm going to look up these set of forwarders that work for bar.com; for everything else, I'll look up these other set of forwarders".
Unioning of domains really bit me in the butt for my laptop use when connecting to the internet and to our corporate VPN. By using local DNS, I also sculpt the packets better by not always trying to resolve against the VPN-provided DNS servers.
If this type of setup was added to NM, it would be very, very nice.
Anyway, just my experience with the issue. YMMV.
On Fri, 2005-07-15 at 15:19 +0800, Jeff Pitman wrote:
If this type of setup was added to NM, it would be very, very nice.
That type of usage is one of the major reasons why we chose to use bind for NetworkManager. I'm not sure if NetworkManager's VPN support takes advantage of it yet, but it could if it doesn't.
On Friday 15 July 2005 20:29, Colin Walters wrote:
On Fri, 2005-07-15 at 15:19 +0800, Jeff Pitman wrote:
If this type of setup was added to NM, it would be very, very nice.
That type of usage is one of the major reasons why we chose to use bind for NetworkManager. I'm not sure if NetworkManager's VPN support takes advantage of it yet, but it could if it doesn't.
If not, you might want to make note the order in which bind comes up and whether the availablility of that particular DNS is available at the time. Bind will blacklist forwarders if they're not available at the time of a resolve. Even if it's up later and good to go. You have to restart bind to get it to resolve against these servers.
Just FYI for any future enhancements that are built around this...
From: "Dan Williams" dcbw@redhat.com
It does work with any static IP address you have configured with system-config-network. It will apply the IP & DNS configuration you've selected using system-config-network Profiles on startup. NM blows away your /etc/resolv.conf because it uses a local caching nameserver to deal with horrible glibc resolver dropouts when network switches occur. That's not likely to change, what may change would be the ability to add custom entries to the caching nameserver's config.
That's fine, but the current behaviour is rather brutal: you start it and everything stops working. That can't be good.
At the very least can you back-up resolv.conf, and maybe restore it when you shut NM down? I guess that can happen even in the init.d script.
Ideally, NM should migrate the content of resolv.conf to bind, so that starting/stopping NM becomes seemless. Also a more explanatory message in the overriden resolv.conf would be appreciated.
-
Colin Walters -
Dan Williams -
Dennis Gilmore -
Dimi Paun -
Jeff Pitman -
Jesse Keating -
Michael A. Peters