2009/8/8 Hadmut Danisch <had...@danisch.de> > Dan Williams wrote: > >> Many packets for debian/ubuntu are designed for the four phases of > >> the ifup/down system of debian for pretty good reasons. > >> > > > > It depends; reasons change, and so do implementations. Nothing is set > > in stone. > > > > Ah, I see. debian and ubuntu will change their main concepts just > to please network manager... >
This wasn't what he said, the statement was that it depends and reasons change. The DBus interface wasn't available before and therefore everything had to get information from and happen as a result of the phase scripts. Now that the DBus interface is there the packages that used the previous methods should be revised and it should be decided whether that really is the most appropriate way of doing things. Maybe it is the case that the DBus interface isn't entirely suitable for whatever reason, but that needs to be looked at on a case by case basis and if appropriate something else can be decided upon/added. > Completely wrong. NetworkManager is *NOT* a Red Hat tool. Novell has > > contributed immensely to it, as have quite a few others from other > > distributions. It just happens that I am paid by Red Hat to spend 110% > > of my time working on NetworkManager. > > > > Nobody else has made that commitment. If some other company or person > > decided to invest time in NetworkManager, then that person or companies > > goals would also obviously be reflected in the feature set of the final > > product. > > > > So network manager is designed to not fit very well into other > distributions? > Again no, network manager wasn't designed to not fit into distribution X, it simply hasn't been adapted to fit into it yet. The way you're saying this it's like NM was designed specifically for redhat and they refuse to change anything to make it fit well with other distributions as well. What was said is that redhat have invested a lot in NM and so of course it is suited well to a redhat environment. If some other distro were to invest heavily (by sending patches for the functionality that was required) then NM would also fit well into that distribution. > So lets add some cold hard facts to the discussion. What things are > > people doing in pre-down scripts? > > > > * Any kind of logout, e.g. release dynamic dns entries, properly > shut down connections that are kept alive during the online state > * cleanly shutting down VPN connections and tunnels > * network logoffs, e.g. deregistration from firewalls to prevent > that someone else uses the user's permissions still bound the IP > address > * Anything that needs to be done with network interfaces that don't > exist anymore after taking them down, e.g. read the counters > * Doing jobs that need the network connection to be present, e.g. > empty the mail queue > * Porperly shutting down daemons with services bound to that > particular network interface or internet address > > > > > > >> Beyond the dispute whether two or four phases should be supported, > >> Network Manager > >> does not pass the required Information to the up/down scripts. > >> > > > > See below. What other information do you need? Is there some reason > > the tools you're running in these phases cannot use D-Bus for network > > even notifications if they are already running as a service somewhere? > > If they are not running as a service, then yes, a one-shot script-based > > approach may be more appropriate. > > > > Using dbus to fetch information in such a basic application is a > completely wrong > way. dbus is not very well documented. When trying to fetch debugging > data to > find the problem in my cause I could not find a detailed description > about how > to fetch attributes from dbus, and it would be a nightmare to do it in a > shell script > (and too slow as well). Documentation is poor and incomplete. Then documentation should be fixed, not the method itself. DBus is the best approach to do this, it uniffies IPC in unix, which is a *good* thing. > requiring each single one of the phase scripts fetch information over > dbus is > simply very, very bad design. If five scripts need that informations > then every > single one should fetch data over dbus even if the network manager already > has them but does not pass for 'religious reasons'? > > Under debian/ubuntu there is a standard about which data the phase scripts > expect, and not all of these data can be found on dbus. > > Needed: > > * The environment variables as set by the ifupdown program > * The parameters set by users to use extra functionality provided by > the phase scripts. Configured in /etc/network/interfaces for every > connection type > * Any parameters passed by the DHCP server > > > > > > > > > >> Expecting the scripts to retrieve details with a given UUID over dbus is > >> error prone and > >> bad design, and it does not make the script run any faster. > >> > > > > The UUID is already passed to the scripts, and has been for a long time. > > As are all the IPv4 details, and the DHCPv4 lease details if any. What > > version of NM are you using? > > > 0.7.1~rc4.1.cf199a964-0ubuntu2 > > > > > > Tools before NetworkManager didn't work for a more dynamic environment > > (especially wifi), thus we created NetworkManager. I certainly don't > > want a pile of shell glued together with duct-tape and chewing-gum, > > which is what most of the previous networking system were. > This is a pretty good approach. > > But unfortunately it takes much more to write a good program. > > Besides the fact that network manager's programming style is poor > (too complex, lack of docs, comments, and debugging, names of little or > no use, > difficult and time consuming to read), it suffers from a main problem: > > Network manager is written like one of those many little tools and gadgets > for a desktop and extremely interweaved with the desktop environment and > it's complex functionalities. You can write a tool for sticky notes or a > timer for > your cup of tea in that way, things that are related to the user only, > but you cannot > write a program that controls the communication interfaces this way. > NM is not interweaved with desktop applications. You're confusing the user settings manager with network manager itself. > You cannot even precisely describe how nm finds its interfaces and > configurations, > and where to start debugging if something goes wrong. The way nm is > driven over > the dbus is one of the most silly methods to drive network interfaces > I've ever seen. It's actually the best way to get the two levels of configuration that I can think of. > You can certainly add the functionality to a network managing daemon to > inform > other programs through dbus that something with the network has changed. > But never ever build a system relevat program in a way that it depends on > things like dbus or notifications and needs a running desktop to be > configured. It doesn't need a running desktop to be configured, and lots of system relevent applications require DBus (it's not a desktop program). > Networking must be able to work even in single user mode in a simple > terminal > with a shell session and must not depend on anything else. Correct me if I'm wrong, but I think it does as long as the daemon is started and the system settings daemon is started. > Or in other words: Network Manager is too much like Windows and too > little like Unix. > Windows had for years a much better way of managing network settings for anyone with wireless or a laptop that moved between work and home. You're now complaining because linux now has something that does that and it isn't the hack-riddled shell script approach which you've been using for the last 20 years. I'm sorry if that seems a little blunt but you've taken every oppertunity to complain that network manager doesn't quite fit your use case yet and you haven't been particularly constructive about it, taking every oppertunity you can to take a shot at the design and the coding style. You can, for now, disable network manager and fall back on the old-style shell script mechanism of managing your network interfaces if you so desire and then return to network manager in a release or two to see if it now fits your criteria. Personally I'd prefer for you to actually participate in a constructive discussion and listen to what other people are saying rather than ranting in a terribly closed off manner. I'm not one of the devs so don't take my opinions as if they come from the networkmanager team, but I am both a user of network manager at home and on the systems I manage for work and it fits my environment well and I'm glad that something like this was finally created. Graham
_______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
