Re: [patch] Support Debian's resolvconf

[Olivier Blin <oblin mandriva com>]

Colin Walters <walters verbum org> writes:

> For example, making 802.11 work really well, and not including ppp and
> idsn.  I know ppp/isdn are probably very important to some people, but
> in good design you have to make some trade-offs.

Well, you want NetworkManager to be *the* universal network management
system, you can't forget those connection types.

> o Support for static IP addresses on 802.11b etc
> o Backwards compatibility 
>
> Now the first item, I guess my thought would be - there's probably about
> 50 networking nerds out there who have hardcoded static IP addresses for
> their wireless networks; are they really important?

Not much, it's not really common, but there's no reason to forbid that
if we can handle it quite easily, without too much complexity in the
configuration system.

> It's really weird to use static IP for wifi in general anyways since
> you have to also do things like hardcode the MAC address of the
> access point etc, or you  don't support roaming basically.

Supporting static IP doesn't mean it will be used for all wireless
networks. Roaming between different wireless networks does work,
whatever their IP attribution method.

> The second item has some importance I understand - but we could discuss
> how to get some basic integration of NM and the existing ppp/isdn
> configuration; this might be basically just sending NetworkManager a
> dbus signal from the isdn script to say "i'm on isdn, don't do
> wired/wireless".  Maybe it's harder than that, I don't know, but again
> we should discuss it.

How would you do that? Would you use tools to configure the ifcfg-*
files as you used to do previously? Or would you modify your tools to
directly apply the configuration in NetworkManager?
That would mean a lot of work.

The abstraction is already done in the ifup scripts, which has the
same interface whatever the connection type.
Furthermore, the effort to add additionnal functionnalities such
support wireless roaming is quite small.

> Sure, you have ifplugd and wpa_supplicant and some network
> scripts...but do they all really form a coherent whole when you put
> them all together?

ifplugd is well integrated in the distribution, a little work is
needed to have good wpa_supplicant support.
But that's not as much work as libifying wpa_supplicant and writing a
similar daemon to do its job.

> For example if you are on wireless through wpa_supplicant and then
> plug into a static IP network, does ifplugd activate the static IP
> address in addition to the wireless?

Yes, we use to run a ifplugd daemon per interface.
Maybe that means a lot of polling, I'll have to investigate.

> Who owns the routing table?

We support multiple default routes, and their priority is configured
using metrics.

> What if both  want to do DHCP, and write out resolv.conf?

That's an interesting problem, and I must admit we don't have a good
solution currently. The NetworkManager approach works quite nicely.

> How does VPN interact with both of these?  How does the user control
> and configure the VPN?

NetworkManager only have some limited VPN support, using vpnc.
But you're right, we don't have this VPN support for now.

>> To me, current network scripts are a good starting point, and I don't
>> find it really difficult to make them mobility-aware.
>
> I would like to convince you otherwise - we really want to see
> NetworkManager become the core of Linux networking, because this is an
> area that is hugely fragmented

There's no way to push it if you don't provide text admnistration
tools. Current NetworkManager is nice for end-users, but system
administrators won't be satisfied with that.

> and having the NetworkManager API always
> available means applications can adjust their programs to dynamically
> respond to network availability via the dbus signals.

Then we just have to define a common API that would exactly respond to
these desktop needs, that is:
- notify applications of the networks status
- allow applications to start/stop the network
It would be a nice improvement.

> The answer is that right now there is basic backwards compatibility with
> ethernet static addressing in the form of simply doing nothing if an
> interface already has an IP address (presumably configured via distro
> scripts).

This means you have two ways of configuring your network devices
currently, that's not good. It's really a major drawback.

-- 
Olivier Blin
Mandriva
Mandrakesoft becomes Mandriva