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

Re: network-manager as default? No!


On Fri, Apr 15, 2011 at 10:03:40AM +0100, Jon Dowland wrote:
> For the record, this was (at least) bugs #432322 and #439917, and I'm extremely
> pleased that the issues have been resolved.  Well done and thank you to all
> involved.

AIUI they weren't resolved, but the scope of the problem was significantly
minimized, which is important to note.  I.e. in testing/unstable wired
ethernet connections are no longer bounced during upgrade/removal.
(again AIUI) In the remaining use cases network connections *are* bounced, but
in the postinst rather than preinst/postinst, which lowers the chance
of Bad Things happening to your network-based upgrades.  And AFAIK such
connections are still torn down during package removal.

> Could those thread participants who have gripes from their last NM experience
> many years ago please confirm that their gripes still apply before continuing
> with the discussion?

(I'll assume that the slightly-less-than-polite[1] nature of this request
 is directed at others, but will field the question anyway)

I use NM on a daily basis, and am somewhere between "generally" and
"very" happy with the experience in the scope that I use it.  I don't
have anecdotal complaints as much as I see some potentially big problems
with having NM be a _default_for_all_installs_.  Plus, I haven't seen (even
after asking) what the benefit is that outweighs these problems:

 * n-m does not support the same level of variety in network configurations,
   which is a regression for some subset of server environments.

 * any bouncing of network connections during package install/upgrade/removal
   is still a regression/risk even if limited in scope.

 * glib isn't the best library on top of which to build such a critical
   system level service[2]

 * it would result in a size/complexity growth to the standard installation.

 * it would require changes in long-standing practices if ifup,
   ifdown, and /e/n/i are no longer the preferred way to handle network

 * requiring dbus, last I checked, would increase the likelihood of upgrades
   requiring manual intervention and/or reboot[4].

Allowing for "but you can always uninstall this and install ifupdown" is
fine[5], except, why should the admin have to do so in the first place,
as opposed to "if you really want network-manager on your server you
can install it"?

I'm not trying to be knee-jerk obstructionist[6] here.  If we decide that
we have good reasons to have a stateful network configuration daemon in
every install by default, so be it, it's not my call anyway.  But the
implementation of *this* stateful network configuration daemon leaves
a bit to be desired and I'm still waiting on what the rationale is for
*why* we want to have it in the first place, hence my voicing of concerns.


[1] "Gripe" isn't really a constructive way to describe what could be
    valid and potentially significant issues.
[2] the glib allocation behavior being one example.
[3] this also would affect *packages* using ifup/etc or the /e/n/if-*.d/* hooks
[4] that'd be #495257 which is a whole other can of worms, and I assume most
    admins would rather we keep servers out of that when possible.
[5] though if you happen to be installing debian on a remote device
    that has a connection other than wired-ethernet, you suddenly have
	problems getting rid of NM without locking yourself out.
[6] nor a "get off my lawn u damn kids, learn to RTFM" type either.

Reply to: