On Thu, 2008-11-13 at 10:36 -0600, Les Mikesell wrote: > Dan Horák wrote: > > Chris Adams píše v Čt 13. 11. 2008 v 10:02 -0600: > >> Once upon a time, Dan Williams <dcbw@xxxxxxxxxx> said: > >>> You can certainly disable NetworkManager and use manual configuration of > >>> your network devices. > >> For how long? I thought I'd read that the plan was to use NM for > >> everything and eliminate /etc/init.d/network. > > > > We will keep/maintain /etc/init.d/network forever :-) They don't > > conflict, so there is no reason to completely drop the old method. > > Who wins if they both want to set the default route and DNS servers? If two equal class devices (ethernet > wifi > mobile broadband) are capable of being the default route, the one detected earliest from HAL wins. The default device's DNS information gets added first, and each active device's DNS information is appended. Thus you can certainly get more than 3 nameservers in /etc/resolv.conf, but 3 is all that the glibc resolver allows. In the future we can resurrect caching nameserver to support split DNS, but that's based on _domain name_, not IP address, so the best solution there, by default (but allow manual override) is to use the DHCP-returned search domains (if any) as the domains to split DNS for. > Chances are that if you have a working statically assigned interface you > would not want to switch them to subsequent DHCP assigned NIC - but on > the other hand if you bring up a VPN tunnel, you might. And does NM Why's that? > know enough to drop routes through an interface that is physically down > (no link, not ifdown) statically assigned or not? If the interface is physically down, NM will deactivate the connection and addresses and routes get flushed. Fine-grained modification of device parameters and configuration while the interface is down/disconnected isn't supported and likely won't be. I tend to think there will be a place for manual network configuration for a long time (no matter what jeremy says :), because there are some situations that are just too borderline to support in the short term, or are sufficiently borderline that the maintenance cost of adding the feature outweighs the benefit of the feature in the first place. There's always a tradeoff to feature addition. Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
