Bug#695221: [Pkg-xen-devel] Bug#695221: confirmed bug, serious
On 18/02/13 19:02, Mike McClurg wrote: Hi all, Sorry for top posting. I spoke with Rob, the author of xcp-networkd, who thinks that he's fixed this bug in a later upstream release. We'll take a look at the repo tomorrow and see if we can find the commit that fixes this issue. Hi Mike, I'm just wondering if you found anything detail about this issue? In particular, is it safe to backport the patch to the version of the tools in Debian, and if not, is the workaround (editing the file by hand) valid? Could you also comment on a couple of related things about the capabilities of pif-reconfigure-ip, so that I can update the README.Debian? - is there any way to set multiple addresses on an interface, within the same subnet, using pif-reconfigure-ip? E.g. if the subnet is 192.168.1.0/24, is it possible to assign both 192.168.1.2 and 192.168.1.3 to the dom0 host using a pif-reconfigure-ip command? - does pif-reconfigure-ip support IPv6 addresses, or there is some other command, or dom0 IPv6 is not possible? - can pif commands be used with dummy interfaces, e.g. to create a dummy0 interface on dom0, assign an IP address and then bridge that dummy0 into an internal network? Or pif commands are only valid for genuine physical interfaces? Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695221: [Pkg-xen-devel] Bug#695221: confirmed bug, serious
Hi all, Sorry for top posting. I spoke with Rob, the author of xcp-networkd, who thinks that he's fixed this bug in a later upstream release. We'll take a look at the repo tomorrow and see if we can find the commit that fixes this issue. Mike On Tue, Feb 12, 2013 at 3:22 AM, Thomas Goirand z...@debian.org wrote: On 02/11/2013 04:22 PM, Daniel Pocock wrote: Having it marked RC may allow a patch into wheezy. Marking it RC is only delaying the release, that's it. I have already fixed multiple bugs which were not marked as RC, and the release team accepted the changes. Even after Wheezy is released, it is possible to fix problems in the stable distribution. Maybe even a small patch: A small patch is what we should all aim at. I'm sure the problem isn't so complicated, and that we can fix it. Of course, it would help if Mike and Jon were a bit more cooperative and were trying to fix the issue, but it seems they are quite busy these days (or maybe in holidays?). - updating the README - changing pif-reconfigure-ip to give an error if the user tries a netmask that is not supported, e.g. XCP only works on a Class C subnet with a netmask 255.255.255.0. Your changes have not been applied. See bug 695221 or the README file. Yeah, I think that is indeed a good idea to write this! These things would be small fixes but would make the user's first experience of XCP less frustrating The last thing you want is for people to get frustrated and start thinking that they should try the Ubuntu version or the ISO installer: http://www.xen.org/download/xcp/index_1.6.0.html#install Well, yes, I would like to have more Debian users, and that people use less XCP from the ISO installer (eg: CentOS based). However, the Ubuntu package of XCP is synced from Debian, so these are the exact same package (with only a possible delay in having the Ubuntu package). Nobody in Ubuntu works on the XCP packaging, the work is only been done by myself in Debian. 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. It's not quite the same, because the release team wouldn't accept a patch/unblock request for a normal issue This statement is completely wrong. The criteria for the release team to accept changes is not the severity of a bug only. If we find a way to fix this problem, I'm quite sure that the release team will accept the patch, regardless of the severity set in the BTS. I'm hoping that the fix for this might be quite trivial and therefore acceptable to the release team. Yeah, that's more in line! If the fix is small, and even trivial, and easy to review for them (which is quite likely to be the case, considering that just fixing the db with an editor fixed it for you), then they will accept it. I'm also quite sure that they would accept any documentation change at this point of the release. Cheers, Thomas
Bug#695221: [Pkg-xen-devel] Bug#695221: confirmed bug, serious
On 11/02/13 03:48, Thomas Goirand wrote:
I don't think it's useful to bikeshed about the severity of an issue but...
I can see you've put a lot of work into this package and I think people
will want to use it, especially when wheezy is released
That's why I'm reporting stuff like this and also providing suggested
solutions (e.g the possible workaround)
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.
snip
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.
I think that comes back to point (a) - if `most' or even a lot of users
are not using /24 (which is not clear to me), and if there is no
workaround, then maybe it is serious
Besides this, I don't think it's reasonable to delay the release of
Wheezy just for this bug.
Having it marked RC may allow a patch into wheezy. Maybe even a small
patch:
- updating the README
- changing pif-reconfigure-ip to give an error if the user tries a
netmask that is not supported, e.g.
XCP only works on a Class C subnet with a netmask 255.255.255.0. Your
changes have not been applied.
See bug 695221 or the README file.
These things would be small fixes but would make the user's first
experience of XCP less frustrating
The last thing you want is for people to get frustrated and start
thinking that they should try the Ubuntu version or the ISO installer:
http://www.xen.org/download/xcp/index_1.6.0.html#install
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.
It's not quite the same, because the release team wouldn't accept a
patch/unblock request for a normal issue
I'm hoping that the fix for this might be quite trivial and therefore
acceptable to the release team.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695221: [Pkg-xen-devel] Bug#695221: confirmed bug, serious
On 02/11/2013 04:22 PM, Daniel Pocock wrote: Having it marked RC may allow a patch into wheezy. Marking it RC is only delaying the release, that's it. I have already fixed multiple bugs which were not marked as RC, and the release team accepted the changes. Even after Wheezy is released, it is possible to fix problems in the stable distribution. Maybe even a small patch: A small patch is what we should all aim at. I'm sure the problem isn't so complicated, and that we can fix it. Of course, it would help if Mike and Jon were a bit more cooperative and were trying to fix the issue, but it seems they are quite busy these days (or maybe in holidays?). - updating the README - changing pif-reconfigure-ip to give an error if the user tries a netmask that is not supported, e.g. XCP only works on a Class C subnet with a netmask 255.255.255.0. Your changes have not been applied. See bug 695221 or the README file. Yeah, I think that is indeed a good idea to write this! These things would be small fixes but would make the user's first experience of XCP less frustrating The last thing you want is for people to get frustrated and start thinking that they should try the Ubuntu version or the ISO installer: http://www.xen.org/download/xcp/index_1.6.0.html#install Well, yes, I would like to have more Debian users, and that people use less XCP from the ISO installer (eg: CentOS based). However, the Ubuntu package of XCP is synced from Debian, so these are the exact same package (with only a possible delay in having the Ubuntu package). Nobody in Ubuntu works on the XCP packaging, the work is only been done by myself in Debian. 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. It's not quite the same, because the release team wouldn't accept a patch/unblock request for a normal issue This statement is completely wrong. The criteria for the release team to accept changes is not the severity of a bug only. If we find a way to fix this problem, I'm quite sure that the release team will accept the patch, regardless of the severity set in the BTS. I'm hoping that the fix for this might be quite trivial and therefore acceptable to the release team. Yeah, that's more in line! If the fix is small, and even trivial, and easy to review for them (which is quite likely to be the case, considering that just fixing the db with an editor fixed it for you), then they will accept it. I'm also quite sure that they would accept any documentation change at this point of the release. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695221: [Pkg-xen-devel] 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 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
