Re: Diskless clients and NetworkManager

[Dan Williams <dcbw redhat com>]

On Thu, 2009-04-30 at 20:23 +0100, Andrew Bird (Sphere Systems) wrote:
> Hi Pablo,
> 	Speaking as a developer of VMC, I find NM's position of being the well known 
> place for applications to find out if they have network connectivity logical, 
> but also frustrating. Not providing an interface for 3rd party connection 
> managers to publish their status means we have to ship our product in a 
> condition that almost all users will find bewildering. Currently we can 
> successfully make a connection to a mobile network, the user then opens 
> Firefox and he is told that it's offline; now that's not user friendly. Of 
> course there are workarounds for Firefox, but there are other apps that do a 
> similar thing, surely we don't have to go and modify them all. Doing that 
> would throw away all the benefit of NM being the well known interface it is. 
> 	In the future I'd like a dbus interface fitting to NM that allows 3rd party 
> apps to publish their online status. Nothing too fancy is required, just a 
> possibility to get ourselves out of the hole we find ourselves in.

"Nothing fancy" is the problem here, because it's not just about
online/offline.  It's about providing applications an interface to
determine information about network connections and network state, which
a simple "am I online" doesn't do.  What you want is really some sort of
3G connection manager plugin interface to NetworkManager, where you
could plug in your own 3G connection manager.  That would require (a) a
stable plugin API which has both benefits and drawbacks, (b) the plugin
to use the existing NetworkManager configuration mechanism for all its
configuration, and (c) provide NetworkManager the IP configuration and
DNS addresses such that NM could then set up the network interface after
the connection.

That's what ModemManager is already.  I'm not quite sure why everyone
doesn't coalesce around *one* 3G modem management service, because
there's enough odd hardware out there that centralizing all the
knowledge in one place has huge benefits.  It's better for users.  The
problem is that we need that service to be in a lower-level language
than Python, because not all platforms have the resources, ability, or
desire run the whole python stack, both due to code size and memory
size.

I used to work on OLPC, which uses Python intensively.  And we didn't
choose Python for its memory usage, and that came back to bite us later.
Java is a ton better than Python there because you can share the
majority of the pages in Java processes with each other; because they
all run on the same VM.  But with Python, you can really only run one
Python process per VM, and you loose all the sharing ability.  Thus
you're left with Python being a memory black hole.  But Java has a much
larger on-disk footprint.  But I digress...

If people think it's a good idea to have *one* low-level modem manager
service with a D-Bus interface that any higher-level connection manager
could use (be it NM or ConnMan or Wader GUI), then lets do that.  Since
it's D-Bus, it doesn't matter whether it's ModemManager or whether you
guys all want to write your own ModemManager implementation in Python.
Whatever.

But the core problem is that network management is a *system-wide*
problem, and you can't just write one component and call it a day.  The
policy needs to make informed choices based on the entire network state
of the machine.  And the configuration of all the network connections
needs to be in *one* place, with *one* format, not spread around in 3
different locations because you're trying to put 2 or 3 connection
managers on the same machine.  There should only be one connection
manager running at any given time, or else you've just (a) doubled your
work and QA, and (b) made it suck for users because configuration is
split up, and (c) behavior is different than they expect.

Fundamentally, NetworkManager + ModemManager and Wader + VMC are trying
to do the exact same thing.  Control 3G connections.  Why do we have
more than one program that controls 3G connections?  Carrier branding
and control?  Territorial issues?  Existing project momentum and
userbase?  What are everyones requirements, and why can't we find one
project that we can make handle all those requirements in a systematic
manner?

Seems to me it would be easier to make ModemManager work better for your
use-cases than to add Ethernet + WiFi to Wader/VMC.  I'm quite open to
whatever suggestions people have for NetworkManager and the applet.
There simply hasn't been enough manpower to do everything that we've
wanted to do with NM, which is why there are things people want out of
NM that aren't yet supported.  If there are issues with NM's
configuration format or interface, I'm quite happy to figure out how to
fix that.  If there are issues with NM's handling of devices and
routing, I'm also happy to figure out how to fix that.

But at the end of the day, focus must be on the users.  Within the NM
framework (ie, letting NM control your primary network connection) we
think that works pretty well.  But it's hard to see how an interface to
NM to let other apps say "hey, I'm online now" without providing the
other benefits of unified configuration store and UI, unified D-Bus
interface for applications to determine network configuration and setup,
and a single UI for controlling all your network connections, would be a
real benefit to users.

Say an application only wants to bring up email or IRC when you're
connected to VPN.  That requires knowledge of configuration of the L2
device (which could be wifi, wired, 3G, bluetooth, a bridge, a bond,
etc) *and* the VPN connection.

Or your software updater, which you may not want to run when on metered
connections like 3G or WiMAX or even Cable+PPPoE.  Now it can just ask
NetworkManager whether it's on an expensive connection.  But were
something else (Wader or VMC or ConnMan) handling the 3G connection
*only*, now the software updater has to ask *all* connection managers
(NM, Wader, ConnMan, etc) what type the connections are.  That's now 3x
or 4x more code than just talking to NM.  And 3x to 4x more QA work.

So, you might say, lets extend the abstracted online/offline service to
contain connection type too.  And then maybe connection "cost" and IP
address too, since some programs might want to use D-Bus for that
instead of SIOCGIFCONF.  Isn't this just recreating NetworkManager with
a more limited API?  And apps would still have to talk individually to
each connection manager for anything more sophisticated.

There's a lot more to the problem than online/offline.  Just talking
about online/offline is hacking around the immediate problem without
making the system as a whole better for the users.  It fixes your
immediate problem, but it doesn't actually make things better in 6
months or a year.

Dan


> 
> Best regards,
> 
> 
> Andrew
> 
> 
> 
> 
> On Thursday 30 April 2009, Pablo Martí Gamboa wrote:
> > 2009/4/30 Dan Williams <dcbw redhat com>
> >
> > > On Thu, 2009-04-30 at 14:06 +0100, Marc Herbert wrote:
> > > > David Sundqvist a écrit :
> > > > > If I set it to be managed by NM, will NM try to manage it in any way?
> > > > > Can I set it to be seen, but still unmanaged? Or maybe I could get NM
> > > > > to always output a connected status instead of a no-connection which
> > > > > triggers firefox offline mode, etc. (should the connection be lost,
> > > > > well, then NM won't be able to detect it anyway due to being frozen
> > > > > on the first page touch).
> > > >
> > > > There seems to be something fundamentally wrong in this no-connection/
> > > > /offline thing. Since NM can be configured to manage _not all_
> > > > interfaces (including none at all) then why are some applications
> > > > wrongly assuming NM is always managing the entire network
> > > > configuration? This seems to be where the bug lies and should be
> > > > fixed.
> > >
> > > Its mostly a distro problem; if NM is not managing your default internet
> > > connection, then you should probably turn NM off when setting up the
> > > machine.
> >
> > Unfortunately, in today's Linux Desktop this will yield some main
> > application unusable, they all rely on the NetworkManager interface for
> > connectivity status. For projects that provide connectivity (ConnMan,
> > Wader, VMC, K-MobileTools, gnome-ppp, etc.) is a frustrating situation.
> >
> > Even thou NetworkManager is the de-facto standard tool for managing
> > connectivity, NetworkManager won't always be the solution for everyone. Say
> > you have a token ring connection, NetworkManager doesn't have plans to
> > support it. Say you provide dial up capabilities, like VMC, Wader, etc. It
> > ain't gonna be nice, users have connectivity but applications are not
> > aware. There are workarounds for applications like Firefox, but it is not
> > something that a noob user will understand or do. For other apps like
> > pidgin, there's no workaround AFAIK. Perhaps Moblin has patched Firefox,
> > pidgin, etc. to listen for ConnMan's signals, but this is only possible on
> > the OEM/distro level - i.e. I'm not gonna ship a patched firefox/pidgin/foo
> > that listens for Wader's signals in my ppa/buildservice, it ain't gonna
> > scale.
> >
> > It is gonna be a though process, but we need to engage all the interested
> > parties on a discussion about how to make applications aware of
> > connectivity changes and come up with a DBus interface that several
> > applications can provide.
> >
> > I have already expressed this concerns to Dan Williams, and I think that
> > @asac thinks something similar.
> >
> > What do you guys think?
> >
> > > The only way you can make intelligent decisions about the network state
> > > on the machine is to make those decisions with *all* the necessary
> > > information, and that means letting NetworkManager control all your
> > > network connections.
> > >
> > > There are situations in which NM is not appropriate at this time, and
> > > those are mostly situations where the primary network connection cannot
> > > be controlled by NM for some reason.  Thankfully, there are not too many
> > > of those.  Network-mounted-/usr is one of those cases, as are cases
> > > where the root device is network-mounted, or where the interface cannot
> > > be touched after exiting the initrd.  For now, I'd suggest using the
> > > static config scripts.
> > >
> > > A bullet-point on my feature list is to handle this case specifically
> > > for wired non-802.1x connections, because all other types require too
> > > much state to just be taken over post-initrd.
> > >
> > > Dan
> > >
> > > _______________________________________________
> > > NetworkManager-list mailing list
> > > NetworkManager-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/networkmanager-list
> 
>