control: severity +2 serious I would call this an RC bug (serious), but not critical It would be critical if the user lost data from some unrelated application, etc It is serious because a) it makes the package and the whole system unusable for all but one very specific network configuration (users with a /24) b) using good old `xm' style Xen I never experienced any issue like this, just using a /26 subnet with xm on squeeze is fine. c) it will lead to a complete loss of connectivity for people accessing a host remotely to set up XCP http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695221#10 refers to a workaround - nothing in the bug report qualifies as a workaround (but I propose one below). The reporter simply explained that he could only make pif-reconfigure-ip work the way it should by specifying a specific network mask (/24). That in itself is not a workaround, it is just an observation about what values work and what values don't work. I can confirm observing this identical issue, I configured a /29 netmask and `ip addr' shows me that my server thinks it is on a /32. This makes the whole host unreachable. I did a `find' in /etc and /var and I located the following file: /var/lib/xcp/networkd.db which contains the value {"interface_config": ......"MY ADDRESS", 32]]] The 32 is the bad subnet mask. Using vi, I replaced it with 29 (for a /29), rebooted, and it came up OK. As I don't know XCP very well, I don't want to suggest this is a valid workaround. Could anyone with more experience confirm if that file can be modified by hand in this case? Is there something else that could come along and clobber that file? Does xcp-networkd need to be stopped before modifying the file safely? If there is a workaround (what I describe above, or something else) for this such that a /29 or some other valid netmask can be enabled, then the bug could probably be downgraded to important but certainly not normal, it is just too disruptive. To extend the scope of what may qualify as a valid workaround: a) is there some valid use case that avoids using pif-reconfigure-ip and just let /etc/network/interfaces manage the IP? b) should the user put a /24 subnet on a dummy interface and configure eth0 or xenbr0 separately from XCP? I also came across this: http://lists.xen.org/archives/html/xen-api/2012-05/msg00104.html which contradicts this: http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution#Setup_the_network.2Finterfaces_file Specifically, the mailing list posts suggests nothing should be in /etc/network/interfaces, but the wiki suggests that the interface should be described in /etc/network/interfaces (even though it will eventually be reconfigured by xcp-networkd later in the boot process)
Thomas Goirand
2013-Feb-11 02:48 UTC
[Pkg-xen-devel] Bug#695221: Bug#695221: confirmed bug, serious
I don't think it's useful to bikeshed about the severity of an issue but... On 02/10/2013 11:45 PM, Daniel Pocock wrote:> It is serious because > > a) it makes the package and the whole system unusable for all but one > very specific network configuration (users with a /24)Using a /24 is all but a "very specific network configuration", it's in fact the most common one.> b) using good old `xm' style Xen I never experienced any issue like > this, just using a /26 subnet with xm on squeeze is fine.This is totally unrelated.> c) it will lead to a complete loss of connectivity for people accessing > a host remotely to set up XCPSure, but it doesn't match the "serious" definition: makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. Besides this, I don't think it's reasonable to delay the release of Wheezy just for this bug.> I did a `find' in /etc and /var and I located the following file: > > /var/lib/xcp/networkd.db > > which contains the value {"interface_config": ......"MY ADDRESS", 32]]] > > The 32 is the bad subnet mask. Using vi, I replaced it with 29 (for a > /29), rebooted, and it came up OK.That's interesting! I've added Mike and Jon as Cc:, hoping that they will be able to tell wtf is going on, and why the db is being wrong.> As I don't know XCP very well, I > don't want to suggest this is a valid workaround. Could anyone with > more experience confirm if that file can be modified by hand in this > case? Is there something else that could come along and clobber that > file? Does xcp-networkd need to be stopped before modifying the file > safely?Mike must know.> If there is a workaround (what I describe above, or something else) for > this such that a /29 or some other valid netmask can be enabled, then > the bug could probably be downgraded to important but certainly not > normal, it is just too disruptive.Ultimately, this is the job of the maintainer of a given package to decide the seriousness of a bug. To me, setting it to either normal or important is exactly the same (eg: it is on my radar, and I really want to have it fix), and discussing the seriousness doesn't help. Discussing ways to fix it does.> To extend the scope of what may qualify as a valid workaround: > > a) is there some valid use case that avoids using pif-reconfigure-ip and > just let /etc/network/interfaces manage the IP?I don't think so. XAPI needs to know how you configure your PIF.> b) should the user put a /24 subnet on a dummy interface and configure > eth0 or xenbr0 separately from XCP?I don't think so.> I also came across this: > > http://lists.xen.org/archives/html/xen-api/2012-05/msg00104.html > > which contradicts this: > > http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution#Setup_the_network.2Finterfaces_file > > Specifically, the mailing list posts suggests nothing should be in > /etc/network/interfaces, but the wiki suggests that the interface should > be described in /etc/network/interfaces (even though it will eventually > be reconfigured by xcp-networkd later in the boot process)As much as I know, you do have to configure stuff in /etc/network/interfaces. This is described in the README.Debian for xcp-xapi, under section 4.2 of the file. Though the networking might be different when using openvswitch, I'm not sure about this. Thomas
Maybe Matching Threads
- Bug#695221: xcp-xapi: xe pif-reconfigure-ip doesn't work with non 255.255.255.0 subnet netmask
- Bug#677395: xcp-xapi: xe pif-configure-ip does not remove old ip from interface
- Bug#680588: xcp-xapi: startup race condition between xcp-xapi and xcp-networkd on slave
- Xen/XCP on Ubuntu 12.04 Server keyboard problems
- [xcp] problem in running xcp-networkd in ubuntu 11.10