Re: network-manager as default? No!
Hi,
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
configuration[3].
* 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.
BR
Sean
[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: