Pkg xen devel - Feb 2013 - Bug#695221: confirmed bug, serious

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)

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 XCP
Sure, 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