On Fri, 2008-11-14 at 15:17 -0500, Martin Langhoff wrote:
On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj(a)redhat.com>
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