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

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces



On 27/05/15 21:12, Christoph Anton Mitterer wrote:
> On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote: 
>> I don't think ifupdown has been "Debian's native tool" for several years
>> now. It is one among several available tools, and happens to be the only
>> one with Debian as its upstream; on a wheezy-era sysvinit system that
>> uses NetworkManager
>
> perhaps on a desktop install... when you have e.g. your bootstrapped
> Debian you won't necessarily see NM at all.

I am not saying that every wheezy-era Debian system has NM, or that
ifupdown has no value in general.

All I am saying is that ifupdown has no *additional* value on those
systems where NM (or wicd, or ConnMan, or systemd-networkd) manages the
network interfaces.

In other words, ifupdown is one choice among many - on wheezy/jessie
servers I currently choose ifupdown (although I should try out
systemd-networkd at some point), but on laptops where I've chosen to use
NM, the only reason ifupdown is still installed is historical inertia.

> Further:
> ifupdown has Priority: important and is Recommended by netbase
> while NM has just Priority: optional

Right. I'm not sure that that's necessarily appropriate any more; it is
certainly not the case that ifupdown is the only way to get networking.

> lo is probably that important that it's justified to bring it up by
> systemd... [...] but at least it
> smells like software bloat.

systemd specifically brings up certain Linux features which are
considered to be "part of the platform API" before doing anything else;
this includes /proc, /sys, and a tmpfs on /run, among other things. It
also places lo in this category: the argument is that if a Linux system
doesn't bring up lo and assign 127.0.0.1 and (if IPv6 is supported) ::1
to it, then that system is just wrong.

Non-lo interfaces do need local configuration and would not be
reasonable to hard-code in the same way, so they are handled separately,
by the infrastructure of your choice (ifupdown, systemd-networkd, NM,
ConnMan, wicd, perhaps others), during the normal "start all the
services" phase of the boot.

    S


Reply to: