[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: starting Fedora Server SIG

On Fri, Nov 14, 2008 at 1:22 PM, Jeremy Katz <katzj 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

 - 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.


 martin langhoff gmail com
 martin laptop org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]