starting Fedora Server SIG

[Dan Williams]

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 at redhat.com> 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