Re: NetworkManager-Ddispatcher preup / predown

[Dan Williams <dcbw redhat com>]

On Fri, 2010-03-19 at 22:02 +0100, van Schelve wrote:
> 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.  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.

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

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

Dan