Re: Network profiles

[Dan Williams <dcbw redhat com>]

On Mon, 2008-11-10 at 11:55 -0800, Robert Smits wrote:
> On November 9, 2008 08:49:15 pm Dan Williams wrote:
> > On Sun, 2008-11-09 at 11:33 -0500, Matthias Clasen wrote:
> > > (resending, since I messed up recipients)
> > >
> > > Hey,
> > >
> > > I saw something call network profiles being committed to
> > > gnome-control-center recently.  I didn't see any prior discussion on
> > > this list. Maybe a little explanation of the plans and purposes behind
> > > this would be good.
> > >
> > > Also, I wonder how this will interact with closer NetworkManager
> > > integration in the future. Medium-term, all network-related
> > > configuration needs to be made dynamic and depend on the current
> > > connections, which are under the contol of NetworkManager.
> >
> > Yeah, I'd be interested to hear exactly what that support is supposed to
> > do.  Network "Profiles" are generally a bad idea, because they are a
> > huge stick trying to solve a problem that's generally better solved with
> > more targeted, intelligent mechanisms.  You can quite often autodetect
> > what "profile" you need to use, and that's exactly what NetworkManager
> > does with it's connections.
> >
> > Now if it's more about mounting your work NFS when at work, and your SMB
> > share when at home, that's fine, but that can certainly automatically
> > key off what NetworkManager connection is currently active, because NM
> > has essentially already determined your location for you...  but in the
> > end, _most_ stuff like printers, network shares, etc, should be
> > auto-detectable.
> 
> It would be really helpful if there was a link to a page describing how to do 
> all this in simple language, and with examples you can follow. Not all of us 
> know how to write or link scripts, etc. 
> 
> One of my pet peeves about Network Manager is that it doesn't do this already. 

It's not really NetworkManager's *core* responsibility, and thus to keep
the NM codebase flexible and maintainable I don't really want to pile
all sorts of stuff into it.  But, since NM uses D-Bus, services on dbus
can listen for the signals and do what they want.  Upstart was supposed
to fill this role for system services, not sure if it's there yet.

Until something like upstart is there, dispatcher scripts are the way to
go.  The script gets a few arguments (device name, action) and the
script's environment is populated with a number of variables relating to
the IP4 and DHCP4 configs of the connection.

Dan