[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: network-manager as default? No!

Patrick Schoenfeld <schoenfeld@debian.org> writes:
> On Fri, Apr 15, 2011 at 02:01:06PM +0200, Bjørn Mork wrote:
>> Josselin Mouette <joss@debian.org> writes:
>> > Since it was completely redesigned, almost from scratch, this doesn’t
>> > apply for 0.8. Its system daemon is able to manage connections without
>> > anyone logged on, and with a number of features that makes ifupdown look
>> > like a baby toy.
>> So Network-Manager has finally gained basic features like the ability to
>> set a lower than default MTU?
> AFAICT n-m had support for setting a lower MTU since 2008.

Great.  Didn't know that.  Couldn't find it documented anywhere, but
that's probably because Network Manager in general is completely

> And with basic network features do you mean things like
> - custom routes per interface

Sure, just add

  up ip route 2001:db8:42::/48 foo dev $IFACE

to the interface config

> - multiple ip adresses per interface

Sure, just add

   up ip addr add  2001:db8:13::1/64 dev $IFACE

to the interface config

> - WLAN configuration

Sure, just add 

   wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

to the interface config

> - 802.11x

Don't to that, but the wpa_supplicant scripts should support it AFAIK.

> - overriding default nameservers per connection

That's actually a feature I try to avoid, as I rarely (if ever?) use a
computer with a single interface.   So which interface defines the

But it can of course be done.  The main problem is knowing which servers
to configure, based on which protocol and which interface, and not doing
the actual /etc/resolv.conf replacement.

> - overriding default search domain per connection

Now, that's a "feature" I find extremely dangerous. So you connect to
host "foo", which turns out to be either "foo.bar" or "foo.baz"
depending on which interface is currently up?  Weird.  Why would anyone
want that?

Yes, it can of course be done.

> - netmasks in CIDR notation

Which would be nice, but staying backwards compatible is more important.

> and all of that 
> - in a central place with a consistent interface

Yes: /etc/network/interfaces

> - without reliance on external commands (such as the ip command or shell
>   scripts) for basic stuff

Which is bad because of what?

Using the "ip" command or shell scripts is an important feature to me.
I don't want "grep", "cp", "ls" etc unified to a single file handling
program either.  I prefer the UNIX way of simple utilities doing *one*
thing and doing that well.

> - without crude hacks (e.g. defining additional interfaces just to bring
>   up another ip)

I assume you are talking about alias interfaces?  Well, that's a kernel
feature from way back and has nothing to do with ifupdown, except that
it supports them.  Which Network Manager doesn't, if I read the BTS

But I rarely use them for additional addresses, no.  I use 
"up ip addr add" instead.

>> The list of features *not* supported by Network Manager is so long that
> Most ifupdown features are not native. Its basically a framework which
> allows *other* tools to provide all the features you named.

Yes, that's why it works.  It doesn't *prevent* you from doing what you

>> I've always believed that peoply chose NM for simplicity.  And I can
>> understand that. It's simple because it doesn't support anything
>> "complex", including common VPN setups.
> ifupdown does not support any VPN setup at all. how does that fit in
> your argumentation?

It doesn't?  Weird.


Reply to: