RFC: new modes in network-manager 0.7 + ifupdown

[Alexander Sack]

On Wed, Oct 08, 2008 at 11:23:50AM +0300, Lars Wirzenius wrote:
> ti, 2008-10-07 kello 11:33 +0200, Alexander Sack kirjoitti:
> >   b. Managed Mode (not default for now):
> >   Devices with a hal interface.name that have a matching static or dhcp
> >   configuration in /etc/network/interfaces will be explicitly managed by
> >   NetworkManager. The ifupdown plugin honours your configuration and
> >   automatically sets the mac address for the managed devices
> >   appropriately.
> 
> As I understand, the point of the managed mode is to make it possible
> for a user to manipulate the interfaces via nm-applet, even if the
> interfaces are configured in /etc/network/interfaces. That's a
> worthy

The final goal is to make the migration of ifupdown users to network
manager as seemless as possible. Whether we ever want full read/write
support for /etc/network/interfaces through NM-applet is questionable
though.


> goal, which I support. So far, though, it seems that it's making life
> miserable for those who don't want give over all their interfaces to
> NetworkManager (because, for example, NM can't deal with their
> configurations). I feel it is necessary to keep ifupdown and NM co-exist
> happily.

Yes, ifupdown certainly has its use cases and NetworkManager is not
ready to be a drop-in replacement.


> > For now, my personal preference is solution 2a). It does not disable
> > ifup/ifdown completely, while it would prevent issues due to devices
> > being accidentially/automatically managed my ifup/ifdown at startup.
> 
> "ifup -a" should (obviously) only be disabled if NM is running in
> managed mode. Otherwise it is too difficult for a system (via init.d) or
> user to bring up their network interfaces. They would have to bring them
> up one by one, which can be quite tedious.

Right, thats what I am suggesting.

> 
> We could teach ifupdown about NetworkManager so that if NM is running in
> managed mode, ifup/ifdown talk to NM to manipulate the interfaces rather
> than doing it directly. Or to give an error message to the user in that
> situation.

I agree, and this is definitly one of the next steps NM has to
take. Probably worth discussing at UDS too.


Thanks,

 - Alexander