Re: Network Manager does not find system wide connections

[Dan Williams <dcbw redhat com>]

On Fri, 2009-07-31 at 09:49 +0200, Hadmut Danisch wrote:
> Alexander Sack wrote:
> > Maybe you have something configured in /etc/network/interfaces? I
> > think there was a report that keyfile connections are not considered
> > if there is anything configured in ifupdown.
> >   
> 
> 
> Sure I have.
> 
> Some things need to be done without graphical desktops and
> without trouble with interchanging between gnome and
> kde. How would one update or repair a system that does not
> start X for any reason?
> 
> I try to deal with eth0 over /etc/network/interfaces on some machines,
> while using network manager for other connections such as UMTS
> mobile phones as a fallback, or VPN connections.
> 
> 
> Nevertheless, In my eyes it is inacceptable to choose such a
> black-box-design for a tool that's so vitally important as a network
> configuration. If it is just guessing and maybe try this, maybe try that,
> and no way to do proper and systematic debugging, and if network
> manager depends on so many other systems like notification,
> gnome or kde storage and other things that nobody can survey,
> then this is bad design. If you don't even know what it is doing and
> why, and what's going on.
> 
> Sorry to say that, but network manager's design is pure bullshit.
> 
> (And btw. it absolutely does not fit into the debian/ubuntu environment.
> Some time ago I issued a list of bugs/problems to the bug tracker,
> but the main author simply did not understand why some things
> need to be done and e.g. why four instead of just two configuration
> phases (pre-/post up and pre/post down) are needed for proper

There are two reasons I've not yet added pre-up and pre-down.  They are:

1) latency - do we expect NM to block the connect process on these
scripts?  If so, for how long?  Should NM have a timeout for each script
before it kills the script and proceeds?  Should NM run them in parallel
or in series?

Each script's execution time makes the connection attempt longer.  Badly
written scripts can make the connection attempt never succeed, hence the
need for a timer and killing of scripts that exceed that timer,  if only
to make it clear what is making the connection take longer than usual.

2) appropriateness
    a) many of the things people used to do in pre-up or pre-down
scripts (munging routing tables, other stuff) are better done by
*modifying the connection config itself*
    b) by the time any pre-down script will run, often the connection
has already gone away (the AP is out of range, the cable has been
unplugged already, etc) so any operation a pre-down script does *cannot*
depend on the interface being up; it must gracefully fail.  Common
things people wanted to do here were unmount network shares; but since
the script must always handle unexpected disconnects (which not all
network file systems do well), you might as well just run this from
post-down anyway.

With 0.7 and multiple active devices, I'm not against *pre-down* scripts
per-se, with the following caveats:

1) any pre-down operation is *advisory*, and the network interface that
the script is called for may no longer be "connected" (associated, cable
plugged in, etc).  The scripts have to understand and account for that.

2) NM wouldn't wait more than 2 or 3 seconds for *all* pre-down
operations to complete, before removing the IP addresses from the
interface or routes from the routing table, because the scripts could be
blocking a re-activation of the device to a new network.  There is room
for optimization here, ie if there is no other connection that the
device can possibly activate at this time (the cable is still unplugged,
or the rfkill switch is flipped, or the device was manually disconnected
at the users' request) then the timeout can be extended somewhat, but
certainly not to infinity.

3) This implies that pre-down scripts would have to run in parallel, so
as to complete within the time given.

The implementation for pre-down would re-factor the dispatcher to create
a "context" for each operation, a UUID for which would be returned to NM
in the response to the dispatch dbus method call.  In NM, the NMDevice
object would then start a timer of 2 or 3 seconds, and cancel that timer
if the dispatcher signaled that it was done running the scripts.
Otherwise, NM would instruct the dispatcher to cancel any running
scripts in that "context" (via the UUID) if the timer fired before the
dispatcher "context" was complete.  NM would then proceed to remove the
IP configuration information from the interface.

Basically, allowing arbitrary "pre-up" and "pre-down" scripts opens the
door to more bug reports and requires more diagnostics when stuff goes
wrong.  Thus, the requirement to *do it right* and ensure that when
somebody writes these scripts incorrectly, that the user does not suffer
the consequences, and that the guilty party (the script) is correctly
identified.

And, as always happens with timeouts, somebody will inevitably ask for
the timeout to be extended because "my use-case just takes a second
longer" without thinking about the actual impact of their request for
everyone else (ex DHCP timeouts), and without fixing the actual root
cause why they need a longer timeout.  That means yet more time spent
writing mails and replying to bug reports.

Dan

> network management.  It is obvious that network manager was
> designed by desktop people writing just another graphical toy
> deeply interweaved with all that complex desktop APIs, but without
> administration and network experience.
> 
> 
> My advice is to throw it away and completely rewrite from scratch.
> At least for debian and ubuntu.
> 
> network manager is really lousy software.
> 
> regards
> Hadmut
> 
> 
>