On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj@xxxxxxxxxx> wrote: > On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote: >> I agree with the desire to maintain only one tool. However, NM is >> extremely desktop oriented, and there seems to include no hint of an >> intention to support the complex setups that are possible with the old >> ifcfg infra. > > Really? Most of the work over the past couple of years in NM seems to > be aimed at trying to support these cases as opposed to just the > "simple" desktop case That's odd -- I've never seen any of it. Are there good examples of how you configure a server to do special stuff with it? Or a 'scripting network-manager' guide somewhere? > The NetworkManager dispatcher stuff has existed forever and is all about > scripting. Not necessarily pre-interface bringup, but post. And > depending on scripting slows things down and makes it a lot harder to > have a deterministic view of what's been done. Network-related events happen very seldom -- so scripting is a good fit. My ifup/ifdown experience is not dominated by bash startup time. > And rather than focusing on nm-tool and exactly what it exposes, it's > probably more interesting to look at the dbus interfaces/daemon > capabilities. Yes, I'll be one of the first to say it's painful to > write code interacting with dbus :-) -- but, it is very flexible and And - it's very far removed from the stuff that a unix sysadmin deals with - it forces me to have a script running to listen to dbus events :-/ > then as what the real use cases that people care about become clearer, > it's easier to write very lean, very specific tools to do what they need > as long as the backend and dbus interfaces are sufficient I'm keen on learning more about the hooks and scriptability, mostly thinking of desktop cases. From a server perspective, running the nm daemon _plus_ running a daemon of my own to listen to dbus events... is not a winning proposition. If the API design of NM is better laid out to do things in a more deterministic way, then great, let's learn those tricks and apply them to a solution that doesn't require fat daemons spinning in the bg all the time (running as root!), and that can hopefully be implemented in shell scripts or something similar. cheers, m -- martin.langhoff@xxxxxxxxx martin@xxxxxxxxxx -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
