Network Manager dependencies

Emmet Hikory persia at
Thu Aug 23 05:20:27 UTC 2012

Dale Amon wrote:
> On Wed, Aug 22, 2012 at 07:40:58PM -0500, Jordon Bedwell wrote:
> > prefer to stay away from it, preference perhaps? But with preference
> > comes the problem that NM relies on wpasupplicant and a couple of
> > other wireless tools that we would absolutely never need on a server,
> > unless we are crazy or there is some one-off sysadmin who has some
> > crazy ideas.
> I agree for the most part... although there are appliances that
> use mobile phone connection as a sysadmin emergency back door
> to get at servers if the host facility backbone is down.

    Consider also the case of mobile servers, which have started to become
available in retail: current devices are things like WiFi<->4G bridge
routers, portable WiFi NAS devices, etc.  We very much shouldn't limit our
conception of what makes sense on a "server" to only that set of things that
happens to make sense for large devices in racks in a data centre.

    That said, ifupdown can currently handle just about any type of network
connection the administrator can imagine, including complexities like
autofailover to VPN over PAN, or arbitrary ESSID WiFi activated by USB
key or local presence of a bluetooth device.

    Where Network Manager shines is in the close userspace coordination of
the selection and activation of network connections, considerably reducing
the advance configuration necessary to adjust to a wide variety of network
options, and allowing users to immediately begin to use hotplug network

    So, rather than debating whether a "server" should be using Network
Manager or ifupdown based on the networking technologies that one might
imagine to be used for some arbitrary hardware in some arbitrary environment,
we should instead consider how we expect the users of the system to interact
with the system we use to define and configure the networks.  Devices with
a single user running interactive processes will likely be better served by
Network Manager (or similar tools), as the user will want to be able to
select from available networking options at will and receive notifications
about the current state of the network.  Devices with few interactive
processes will likely be better served by ifupdown, as the administrator
will want to configure the networking options once, and allow users to
attach to network services exposed once the network comes up.

    Of course, as the tools continue to advance, some other selection may
make sense in the future, but even then I think we should continue to debate
the tools in terms of how the system is expected to be used, rather than
what hardware is present, or into which environment we expect that hardware
to be placed.


More information about the Ubuntu-devel-discuss mailing list