On Fri, 2008-11-14 at 15:17 -0500, Martin Langhoff wrote: > 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. > Brainstorming here, but do DBus services come with some form of documentation format? If so, it it possible to generate a man page per service, and ship it in the rpm, as one step towards making DBus more accessible to old-school Unix types? Hope this helps Dave -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
