On Sun, 2005-07-31 at 15:15 +0200, Olivier Blin wrote: > Ok, but you could have enhanced the current system to have this kind > of status reporting. Currently, I guess you have lost the ability to > manage ppp connections, dsl connections and isdn connections in > NetworkManager. I think a big component of the design thought behind NetworkManager is to make the "common" case work really, really well, even if that comes at the expense of some of the less-common cases. 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. I don't think it's impossible to "support" these things in NetworkManager, be that some basic integration with and awareness of existing distro tools for these connection types, or implementing it all in NetworkManager if that proves necessary. > Right, the network scripts can't handle that currently, but it's quite > easy to add this feature. In Mandriva, I plan to use wpa_supplicant as > default roaming daemon for wireless interfaces. So the wireless > settings would be configured in wpa_supplicant.conf. Then, the network > level parameters (IP settings, DHCP) could be configured in > per-wireless-network configuration files. We could use files named by > the ESSID or BSSID to store this settings, in for example > /etc/sysconfig/network-scripts/wireless So there's a lot of implementation details here; what are you getting over NetworkManager (as it stands today)? As far as I can see, you get: 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? 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. Maybe in specialized situations the static IP makes sense, but we should sit down and talk about what those situations are and think about the problem rather than just deciding that since it was supported before, it has to be in the future. 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. > To have a dynamic behaviour, the network scripts only miss ifplugd and > wpa_supplicant support. We already have both in Mandriva, we just have > to allow to use the two daemons for the same interface. No offense but this feels pretty handwavy to me :) 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? 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? Who owns the routing table? What if both want to do DHCP, and write out resolv.conf? How does VPN interact with both of these? How does the user control and configure the VPN? A lot of thought has gone into these issues in NetworkManager, and I think they've been solved pretty well. > 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 and having the NetworkManager API always available means applications can adjust their programs to dynamically respond to network availability via the dbus signals. > Fair enough. > So, you're currently using network scripts for corporate servers and > NetworkManager for desktop. Do you have some migration scripts to > handle the transition in the future? 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). There isn't compatibility with existing ppp/isdn, but that may not be too hard to do as I said above.
Attachment:
signature.asc
Description: This is a digitally signed message part