On Fri, Dec 14, 2012 at 10:23:58PM +0100, Tollef Fog Heen wrote:
> > I think it's important that an upgrade of the NM package *also* not cause
> > the network to drop, but that's a slightly different point than the one I
> > was meaning to make.
> My question then still stands: Do you consider NM in any way special
> here or does the same requirement apply to other network-providing apps?
I think NM is quantitatively different from other network-providing
packages, but not qualitatively so, because NM purports to manage the
primary network connection. If you're remotely connected to a machine over
openvpn, and you upgrade the openvpn package, and you are then surprised
that the connection drops in the middle while the openvpn server restarts,
well... that's a bug, but I'm not sure why you as the admin weren't
prepared to deal with that. OTOH, if you upgrade the quagga package and it
flushes your entire network's BGP table (to take a historical example),
that's a serious issue.
So NM is special in that it's important. Other packages that provide
similar management of the primary network connection are similarly
important.
> > The policy requirement isn't that *filesystem* changes be preserved, it's
> > that *configuration* changes be preserved. In what way does deleting
> > /etc/network/interfaces constitute a valid configuration that must be
> > preserved?
> The policy requirement is not that the configuration changes are
> valid.
The policy requirement specifically says that:
Configuration file handling must conform to the following behavior:
* local changes must be preserved during a package upgrade
You're right that validity is not mentioned. But I consider this a very
broad gray area open to interpretation, and I think all of the following are
legitimate, non-buggy (and especially not RC-buggy) actions for a package to
take:
- update a configuration file on upgrade to drop deprecated,
user-specified configuration options that are no longer supported (and
which may cause the package to stop working)
- convert the configuration file on upgrade from one format to another,
preserving any user changes to the configuration settings but not the
text of the config file
- modify a config file to recover from known software-induced damage, even
though it is impossible to determine with certainty that a particular
file was damaged by software vs. by explicit admin action
- recreate a template config file on upgrade if missing, where the
contents of that config file correspond to the default behavior of the
software when not configured at all
- fail to complete package configuration while the config file is invalid,
requiring the admin to fix it manually.
I think recreating a stock non-conffile config file when it's been removed
is just one more point along this continuum. You might consider it a bug to
recreate the file, but I see no basis for considering it a policy violation.
And by the way, if you're going to treat it as a serious bug, you'd better
get filing other bugs for consistency. Just off the top of my head,
base-passwd has had the same handling of /etc/passwd for *years* without
anyone objecting. To me, this is very clearly a matter of moving the goal
posts.
> It's not ok to replace a config file just because it has a syntax error in
> it, is it? Also, see below.
Replace, no. Repair, maybe.
> > When ifupdown recreates the file, it populates it only with a
> > config for lo. I don't think it's reasonable to claim that it's valid and
> > intentional to configure a system in such a way that it will fail to bring
> > up the loopback interface on boot. In fact, booting the system without lo
> > breaks so many assumptions that Ubuntu, for example, *unconditionally*
> > brings up lo on boot, whether or not it's configured in
> > /etc/network/interfaces. I consider restoring a stock /e/n/i on package
> > upgrade to be in the same category.
> Putting «iface lo» into /etc/network/interfaces is not only a way to
> ensure there is a loopback interface on boot. It's also a way for
> ifupdown to claim to handle that interface (this is a natural
> consequence of the CTTE ruling; that ifupdown is special and has
> precedence and other tools should stay away from interfaces where there
> is a ifupdown configuration for the interface), so if ifupdown does add
> that configuration, there is no way for me to have ifupdown installed so
> I can read the man page at the same time as letting other tools manage
> lo.
I don't see where the previous TC ruling says that ifupdown is special.
Rather, it says that upgrading gnome-core shouldn't cause network-manager to
clobber the user's network preferences on upgrade, /whichever/ tool they
were using to manage those.
That should be trivially easy in the case of lo. If the /e/n/i entry for lo
is missing, or matches this:
iface lo inet loopback
... it's fair game. If it's something else, then /against all reason/, the
user has configured lo in a non-standard way, and NM should respect that.
So I don't think this bug in ifupdown in any way blocks NM from being able
to do the right thing. If you disagree, let's explore this further.
> I might also dislike the name «lo» for loopback and rename the lo
> interface to something else, and let «lo» be the name of yet another
> interface. It's a bit crazy
I agree with the "crazy", but not with the qualifier ("a bit"), and
therefore don't find this at all persuasive. Policy violations are
release-critical bugs not because we love rules in the abstract, but because
such bugs cause real problems for how packages interact with one another and
for how administrators interact with the system as a whole. A *technical*
policy violation which has no practical impact on any users except those of
the mad scientist variety who go out of their way to violate assumptions
about the base system should not be a release-critical bug, or even be
flagged as a policy violation, IMHO.
> , but not much cares about network interface names apart from the network
> configuration tools, so this would actually break a most unusual, but
> otherwise valid configuration of the network stack. ifupdown would break
> that configuration.
To be clear, the full scenario being described is:
- the user has renamed the loopback interface in the kernel (presumably
using a udev rule), and renamed another, real network interface 'lo'
- the user has then configured these network interfaces using
network-manager
- the user has removed /etc/network/interfaces from the system instead of
leaving an empty or commented-out file
Even setting aside the fact that taking a name from one network device and
giving it to another is largely full of kernel/udev race lulz, I don't see
any way that this scenario is something Debian should be concerned about
supporting.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature