On Sat, 2009-08-01 at 00:58 +0100, Timothy Murphy wrote: > Brian Morrison wrote: > > >> I do not believe that it was a good idea to use nm as a standard > >> software tool in ubuntu. > > > > Works perfectly fine in Fedora.... > > You should say, "It works fine for ME in Fedora". > It is obvious from the Fedora newsgroups that many people > have serious problems with NM. > > I don't, personally, but I find the complete lack of documentation > a major drawback with NM. > The whole point of Linux is that it is not magic; > you are meant to be able to work out what is going on.
It's pretty simple. NM takes connection configuration from a few sources, and applies that to network interfaces based on certain criteria. Those criteria are: (a) whether the connection is available, ie whether the wifi network can be seen or whether there is an ethernet carrier, or (b) when the user tells NM to do so. That's it. Seriously. Where it gets complex is because people expect it to interact seamlessly with their normal distribution's config files and mechanisms, and for finer-grained security so you don't need to be root to do everything. a) distro config files: we've added interpretation of you distros config files to NM. In many cases, those config files operated like bash scripts with variable subsitution and backtick commands, etc. So the mapping isn't always exact, and that's sometimes confusing. However, for many people, it's a lot less confusing than learning a completely new configuration system, and building up new tools to work with that config system. For example, /etc/resolv.conf is *not* static, because lots of things need to update it (vpns, ppp, dhcp, etc). In Fedora, people were confused when /etc/resolv.conf was rewritten periodically by NM to accomodate VPNs or mobile broadband, etc. Because in reality resolv.conf cannot be static (yet some people expected that because it had always worked that way before), they were surprised when this happened. Instead, placing the DNS information into the connection configuration itself, instead of out-of-band in resolv.conf, fixes this issue. b) DNS indirection: Debian uses resolvconf to mediate /etc/resolv.conf, which duplicates a large part of what NM does. Various bugs and other issues with resolvconf have led to some frustration when user's blame NetworkManager for blowing away their /etc/resolv.conf (and of course don't understand how things work because the interactions are complex). In it's most simple use-case, NM completely manages /etc/resolv.conf and we don't have these problems. c) permissions: much of the time, you don't want to have to become root just to connect to a different network. However, most of the older tools required SUID or sudo or some other privilege escalation mechanism. Additionally, making that complete mechanism (executed by the user) SUID made security vulnerability windows larger. By using PolicyKit, we can grant users only the permissions they need, *or* grant them all permissions if they so desire. Thus, users can control networking with only the permissions they need, instead of having to grant the user access to an entire unix group (debian-style) or using SUID binaries (console-helper, Fedora style). These are some of the ways that NM is unfortunately more complex than previous script-based networking systems. A combination of user-driven requirements and security-based goals. Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
