Re: Network profiles

[Dan Williams <dcbw redhat com>]

On Mon, 2008-11-10 at 14:21 -0800, Robert Smits wrote:
> On November 10, 2008 01:37:03 pm Dan Williams wrote:
> > 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.  
> 
> I don't want "all kinds of stuff" in it - I just want the obvious stuff when 
> you make a connection - populating the nfs or samba network should be an 
> obvious chore for a "network manager".

Some people want network shares, others want printers, others want NTP
updates, others want proxy configuration, some want hostspot auto-login,
where do you draw the line?  "Obvious" means a lot of different things
to people.

Thus, I draw the line for what code goes into the NetworkManager daemon
at: core network management tasks relating to IP-level connectivity.
What additional tasks are performed once you have IP-level connectivity
isn't code that I think should be in the core NetworkManager daemon.

NM should *certainly* provide the mechanisms (and it already does) by
which these things can be handled easily and transparently, but going
forward I don't want to maintain the devil-child of an octopus and an
elephant.  Essentially, what we need is a service that listens for and
responds to network events based on what you want done.  Call it a
"location" service or an "event" service.  Sounds a lot like what
upstart is trying to be.

Dan

> > 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.
> 
> But most of us have no idea what a dispatcher script is, how to write it, 
> where to put it, etc. This is not a chore endusers ought to have to deal 
> with. If there were some examples to look at, I might take a stab at it, 
> though.
> 
> 
>