Re: NetworkManager-Ddispatcher preup / predown

[van Schelve <public van-schelve de>]

>> Hi.
>> 
>> I know about several discussions about pre-up and pre-down in the past.
>> Dan, I understand your position and I can follow your arguments
against.
> 
> Yes, I realize there are use-cases where such operations would be nice
> to have, and I'm open to it.  I haven't gotten around to reviewing the
> patch yet though, and it's a fairly major change to the flow of things
> so it's not something to be undertaken lightly.
> 
>> But I see a number of usecases where I dont have any idea instead of
>> doing
>> it with pre-up / pre-down scripts in nm-dispatcher. I know every script
>> in
>> these phases is a potential risk for nm functionality. From nm site you
>> have no chance to control those scripts and it might be that users will
>> come up with problem reports that are based on their own scripts.
>> 
>> For example. We need to find solutions for these problems:
>> 1. unmount cifs shares before a connection becomes disconnected
> 
> Right, but remember that this is only possible *sometimes*.  There will
> always be times where the connection just died and no clean
> disconnection is possible.  
I know. The example was using mounts over wlan. Bad Idea. Let's talk about

Ethernet and laptops. Laptops can be either in a docked environment where 
the Ethernet cable is in the dock or they are direct connected. So what
we would like to do is: automatically unmount existing mounts using acpi
undock event based scripts (user has to press the dock button), unmount
in the case a user suspend his laptop, or undock in pre-down phase.

So if the user decides to unplug the Ethernet cable from his laptop
**before**
disconnecting from the network he has to live with a hanging system. We
told
him before.

> But in cases where it's possible to do so,
> we should probably try to give these operations at least a few seconds
> to complete before killing the connection.
 
Ok, if you are saying "a few seconds" then users should be able to
configure
the value for this in the global configuration.

>> 2. stop any other active connection when a user select another one
(maybe
>> this can also be done in down event) to make sure the system is single
>> homed
> 
> I don't really see the value of this actually.  In practice, the
> multi-homing is not an issue and it should be transparent.  Multi-homing
> is also required for less interruption in network connections.  If you
> had to wait 30 seconds to connect to a wifi access point after
> unplugging a cable every time, that's annoying.  I'll also note that
> Windows and Mac OS X have been multi-homed by default for years.
>
Yust one example: A user connects to 3g with his internal modem. The
signal
is bad and he decides to connnect via bluetooth cell phone (he can put it
on a windowsill to get a better signal). So he has two ppp based
connections
active. How do we control that the bluetooth based is the preferred?

>> 3. disconnect from the active vpn before the underlaying connection
>> becomes disconnected
> 
> Yes.
> 
>> 4. start replication of the mail client before really disconnecting
> 
> Yes, though this has the potential to take a really long time.  How long
> do we give something like this?  I'm not sure I see a usable way to do
> this sort of thing if you have say some megabytes of mail to pull over a
> slow connection, for example.  It might work some places, but certainly
> not many other places like 3G connections. 

That's why I would do it only in Ethernet based connections 

> This one needs more thought
> about what the workflow would be like.  How does the user indicate their
> desire to disconnect?  How do we know how long they are willing to wait
> before they really do want to take their laptop with them?  etc.
> 
>> Maybe I'm off the track looking fixed to pre-up / pre-down as solution
>> for
>> these problems. If so please point me onto the right way.
> 
> Most of these are pre-down really; the major use-cases I've seen for
> pre-up have been stuff like captive portal login scripts.  I went
> through all the pre-up and pre-down scripts in an Ubuntu install last
> year, and 80% of them were completely bogus things like munging the wifi
> attributes, or working around out-of-kernel wifi driver bugs, or other
> stuff that no longer needs to be done.  But there are some valid cases
> like you suggest.
>
I'm really sure that I could give you a number of interesting use-caes but
therefore it's necessary to have the whole picture about what we are
doing.
I can tell you: it's exciting...

> Dan

Hans-Gerd