[NetworkManager] blacklisting auto dhcp interfaces in gutsy

[Alexander Sack]

On Mon, Sep 10, 2007 at 12:19:00PM +0100, Scott James Remnant wrote:
> On Mon, 2007-09-10 at 12:05 +0100, Matt Zimmerman wrote:
> 
> > On Mon, Sep 10, 2007 at 12:38:57PM +0200, Alexander Sack wrote:
> > > On Mon, Sep 10, 2007 at 10:23:06AM +0100, Matt Zimmerman wrote:
> > > > On Mon, Sep 10, 2007 at 10:23:42AM +0200, Alexander Sack wrote:
> > > > > On Fri, Sep 07, 2007 at 06:25:24PM +0100, Matt Zimmerman wrote:
> > > > > > I'm afraid I'm not up to speed on the technical issues involved here, but
> > > > > > the proposed change in behaviour would be a regression for users.  If I
> > > > > > understand correctly, folks who installed 7.04 and are happily using
> > > > > > network-manager (with the default 'auto dhcp' entries in /e/n/interfaces)
> > > > > > would suddenly see it stop working.
> > > > > > 
> > > > > 
> > > > > Yes, if we don't provide an upgrade path to correct this, those
> > > > > users will suddenly see it stop working. However, there are also
> > > > > things to win: For instance you finally will be able to go to network
> > > > > admin in gnome, configure your connection as dhcp and just use that
> > > > > without network-manager getting in your way. Currently your only
> > > > > choice to use the auto dhcp /e/n/i feature is to purge
> > > > > network-manager ... which can't be the right answer imo.
> > > > 
> Actually, you should also be able to do something like this:
> 
>   auto eth0
>   iface eth0 inet dhcp
>     do-not-use-network-manager

... so you suggest that gnome network-admin is fixed to add that
option when you select dhcp for that interface?

> 
> It doesn't matter what the extra bit is, as long as it's there; note
> that NM will ignore any stanza more complicated than the usual two
> lines.
> 
> This is there so that NM ignores things like:
> 
>   auto eth1
>   iface eth1 inet dhcp
>     wpa-essid blah
>     wpa-key foowibble
> 
> Since that's a fixed detail anyway, but can be used for the "don't use
> NM with this interface" edge-case.
> 
> 
> Long term, it's probably best for NM to parse /e/n/i and actually use it
> properly; e.g. treat values there as hard-coded.  So if you had a
> wireless interface defined in /e/n/i like so:
> 
>   auto eth1
>   iface eth1 inet static
>     address 1.2.3.4
>     wpa-essid blah
>     wpa-key foowibble
> 
> Then NM would just ensure that the interface, when up, had those
> details.  And would obviously check ifstate, etc.
> 
> Then it wouldn't matter whether NM was used or not, because the effect
> would be identical to using /e/n/i itself.
> 
> That would require more improvements to NM to make it inherit existing
> interface configuration, rather than blatting it on startup.

This is all fine ... however, remember that network-manager cannot
(and doesn't want to) deal with mulitple connections at the same time
... so lets assume we have:

 auto eth0
 iface eth0 inet dhcp

 auto eth1
 iface eth1 inet dhcp

 auto eth2
 iface eth2 inet dhcp

Which interface should we keep up ... and which one should be downed
when network manager comes up? How can we find a sane heuristic?

> 
> A fair amount of work, really.

Is it worth it? Just blacklisting dhcp eth0 interfaces probably gives
most users what they want, doesn't it? Which cases do you see that
really justify to put a large amount of work into this and probably
end up with something that isn't in line with network manager.

> 
> > >  3. advance users that want a mix of both (wired through /e/n/i auto
> > >  dhcp, but wireless still managed through NM); they don't have the
> > >  option to purge network manager and thus only have the /e/n/i
> > >  workaround as a fallback.
> > 
> > Again, in use case language:
> > 
> > Alison installs an Ubuntu laptop, but she really wants her primary
> > ethernet
> > interface to be nailed up and not subject to Network Manager's whims.
> > She
> > adds the interface to /etc/network/interfaces, and Network Manager
> > then
> > ignores that interface, still allowing her to use it for wireless
> > connections when traveling.
> > 
> This would require improvements to NM and the policy agent to allow
> interfaces to be simultaneously up.  It's possible to do, the "only one
> up at a time" is simply a policy decision in nm-applet; not a hard
> limitation.

Its not really allowed within the bounds of NM philosophy ... it
assumes that you have exactly one managed connection online. NM is
just not prepared to have multiple connections online. Why not just
draw a line and stop mixing up /e/n/i with network manager concepts?

 - Alexander