[libvirt] dnsmasq supporting RA instead of radvd patch
I have a working patch to have dnsmasq support RA instead of radvd. However, something has come up and it will be a week to ten days before I can get it in shape to submit. The current patch has three variables added to the _virNetworkObj structure: dnsmasqRA flag and both major and minor values for the dnsmasq's version. I use "dnsmasq --version" and then parse out the major/minor version values. If major>2, then dnamsqFA=1. If major=2 and minor>=63, then dnsmasqRA=1. For all other cases, dnsmasqRA=0. Code is added to the radvd functions which checks dnsmasqRA and exits if it is 1. Code is added to the dnsmasq configuration file if dnsmasqRa=1. If dhcp-range or dhcp-hosts is specified for IPv6, then enable-ra is added for stateful (dhcpv6). Otherwise, a special "dhcp-range=<ipv6-subnet-address>,ra-only" so that the ManagedFlag will be off in the RA packets for stateless operation. OK, how does that sound? Everyone comfortable with that? Another thing is that I plan to add a test such that if the radvd executable is not valid, the dnsmasqRA=1. As I was doing this, I also looked through the libvirt.spec file. My, what a wonderful example of wizardly that is. Anyway, I thought some updates may be in ortder: - increase the minimum version for dnsmasq from 2.41 to 2.48. - why is radvd required for rpmbuild? - in light of my patch, make radvd an optional runtime requirement. I am not a spec file expert by any means but there must be a way to not require radvd if dnsmasq >- 2.63. Comments? Gene
On 11/07/2012 02:05 PM, Gene Czarcinski wrote:
As I was doing this, I also looked through the libvirt.spec file. My, what a wonderful example of wizardly that is. Anyway, I thought some updates may be in ortder:
- increase the minimum version for dnsmasq from 2.41 to 2.48.
That's probably safe, since it still works for RHEL 5.9.
- why is radvd required for rpmbuild?
So that ./configure finds the radvd binaries, and encodes the correct location into the built libvirt, for the case where libvirt will be using radvd. The dependency makes sense for distros where we plan on using radvd, but can be made conditional so that we skip it on distros where using dnsmasq alone is sufficient.
- in light of my patch, make radvd an optional runtime requirement. I am not a spec file expert by any means but there must be a way to not require radvd if dnsmasq >- 2.63.
Yes, we can alter the spec file to make things conditional. For example, we have conditions for using init scripts in Fedora 16 and RHEL 6, but systemd scripts in Fedora 17 and RHEL 7 (on the assumption that when RHEL 7 is finally released, it will probably be based on Fedora 17 or later); so whether we depend on cgconfig or systemd is determined by which distro we are building for. In the same way, we could make it conditional that if you are building for Fedora 19 or RHEL 7 you get dnsmasq doing everything, but for RHEL 6 or Fedora 18 (where dnsmasq won't be new enough), we stick to radvd. Don't worry if you don't know quite how to get the spec file to express that; if you can merely draw up the table of preferred versions in relation to the default installs in Fedora releases, we can help turn it into spec syntax. In fact, worrying about Fedora alone may be sufficient; the RHEL conditionals are best maintained by Red Hat since they are the ones choosing what to backport. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 11/07/2012 04:16 PM, Eric Blake wrote:
On 11/07/2012 02:05 PM, Gene Czarcinski wrote:
As I was doing this, I also looked through the libvirt.spec file. My, what a wonderful example of wizardly that is. Anyway, I thought some updates may be in ortder:
- increase the minimum version for dnsmasq from 2.41 to 2.48. That's probably safe, since it still works for RHEL 5.9.
Actually, RHEL 5.9 (and therefore CentOS 5) is stuck at dnsmasq-2.45, and there's very little chance it will ever be rebased again. So if the minimum version is going to be increased, it should be done conditionally according to the release version.
- why is radvd required for rpmbuild? So that ./configure finds the radvd binaries, and encodes the correct location into the built libvirt, for the case where libvirt will be using radvd. The dependency makes sense for distros where we plan on using radvd, but can be made conditional so that we skip it on distros where using dnsmasq alone is sufficient.
BTW, we'll want to do some reasonable testing of this replacement before foisting it on everyone.
On Wed, Nov 7, 2012 at 3:05 PM, Gene Czarcinski <gene@czarc.net> wrote:
I have a working patch to have dnsmasq support RA instead of radvd. However, something has come up and it will be a week to ten days before I can get it in shape to submit.
The current patch has three variables added to the _virNetworkObj structure: dnsmasqRA flag and both major and minor values for the dnsmasq's version.
I use "dnsmasq --version" and then parse out the major/minor version values. If major>2, then dnamsqFA=1. If major=2 and minor>=63, then dnsmasqRA=1. For all other cases, dnsmasqRA=0.
Code is added to the radvd functions which checks dnsmasqRA and exits if it is 1.
Code is added to the dnsmasq configuration file if dnsmasqRa=1. If dhcp-range or dhcp-hosts is specified for IPv6, then enable-ra is added for stateful (dhcpv6). Otherwise, a special "dhcp-range=<ipv6-subnet-address>,ra-only" so that the ManagedFlag will be off in the RA packets for stateless operation.
OK, how does that sound? Everyone comfortable with that?
Another thing is that I plan to add a test such that if the radvd executable is not valid, the dnsmasqRA=1.
As I was doing this, I also looked through the libvirt.spec file. My, what a wonderful example of wizardly that is. Anyway, I thought some updates may be in ortder:
- increase the minimum version for dnsmasq from 2.41 to 2.48.
- why is radvd required for rpmbuild?
- in light of my patch, make radvd an optional runtime requirement. I am not a spec file expert by any means but there must be a way to not require radvd if dnsmasq >- 2.63.
Comments?
Gene
I'm still not thrilled that you're pushing forward with requiring 2.63 + a few patches backported from 2.64 into 2.63 and only checking against 2.63. -- Doug Goldstein
On 11/07/2012 04:23 PM, Doug Goldstein wrote:
On Wed, Nov 7, 2012 at 3:05 PM, Gene Czarcinski <gene@czarc.net> wrote:
I have a working patch to have dnsmasq support RA instead of radvd. However, something has come up and it will be a week to ten days before I can get it in shape to submit.
The current patch has three variables added to the _virNetworkObj structure: dnsmasqRA flag and both major and minor values for the dnsmasq's version.
I use "dnsmasq --version" and then parse out the major/minor version values. If major>2, then dnamsqFA=1. If major=2 and minor>=63, then dnsmasqRA=1. For all other cases, dnsmasqRA=0.
Code is added to the radvd functions which checks dnsmasqRA and exits if it is 1.
Code is added to the dnsmasq configuration file if dnsmasqRa=1. If dhcp-range or dhcp-hosts is specified for IPv6, then enable-ra is added for stateful (dhcpv6). Otherwise, a special "dhcp-range=<ipv6-subnet-address>,ra-only" so that the ManagedFlag will be off in the RA packets for stateless operation.
OK, how does that sound? Everyone comfortable with that?
Another thing is that I plan to add a test such that if the radvd executable is not valid, the dnsmasqRA=1.
As I was doing this, I also looked through the libvirt.spec file. My, what a wonderful example of wizardly that is. Anyway, I thought some updates may be in ortder:
- increase the minimum version for dnsmasq from 2.41 to 2.48.
- why is radvd required for rpmbuild?
- in light of my patch, make radvd an optional runtime requirement. I am not a spec file expert by any means but there must be a way to not require radvd if dnsmasq >- 2.63.
Comments?
Gene
I'm still not thrilled that you're pushing forward with requiring 2.63 + a few patches backported from 2.64 into 2.63 and only checking against 2.63. I assume you are talking about dhcpv6 and not radvd. Thus, your concerns are related to, if dnsmasq's version => 2.63, then use dnsmasq to support both statefull (ManagedFlag on) and stateless (ManagedFlag off) IPv6.
DHCPv6 does work in dnsmasq-2.63 but not very well with respect to libvirt. Libvirt plus my patch to add interface= will allow one DHCPv6 dnsmasq. With the two patches, everything works as it should. If you do not specify any dhcp-range= or dhcp-host= parameters, then it does not matter and everything works as it should. If you do specify them, then you will (at best) get some indication with a message to syslog and, at worst, nothing happens and DHCPv6 requests are ignored. The good news is that I have gotten the attention of dnsmasq's Fedora maintainer and he is looking into it. I expect an update for Fedora "real soon now" and, since Simon said that dnsmasq-2.64 should be available "real soon now," that 2.64 be added to F18 updates sooner rather than later. There are currently NO checks as far as the DHCPv6 implementing code. If you specify dhcp-range or dhcp-host, the parameters will be passed to dnsmasq. I could add a check, and if the dnsmasq is earlier than 2.63, to fail dnsmasq startup. I could also issue a warning message is dnsmasq is 2.63. I have not done that because, if you do NOT specify dhcp-range and/or dhcp-host, nothing will happen and things work as they do now. I noticed that your email has @gentoo,org. I had a fleeting look at gentoo a bunch of years ago. I do not know what problems result in your concern. Gene
On Thu, Nov 8, 2012 at 7:08 AM, Gene Czarcinski <gene@czarc.net> wrote:
On 11/07/2012 04:23 PM, Doug Goldstein wrote:
On Wed, Nov 7, 2012 at 3:05 PM, Gene Czarcinski <gene@czarc.net> wrote:
I have a working patch to have dnsmasq support RA instead of radvd. However, something has come up and it will be a week to ten days before I can get it in shape to submit.
The current patch has three variables added to the _virNetworkObj structure: dnsmasqRA flag and both major and minor values for the dnsmasq's version.
I use "dnsmasq --version" and then parse out the major/minor version values. If major>2, then dnamsqFA=1. If major=2 and minor>=63, then dnsmasqRA=1. For all other cases, dnsmasqRA=0.
Code is added to the radvd functions which checks dnsmasqRA and exits if it is 1.
Code is added to the dnsmasq configuration file if dnsmasqRa=1. If dhcp-range or dhcp-hosts is specified for IPv6, then enable-ra is added for stateful (dhcpv6). Otherwise, a special "dhcp-range=<ipv6-subnet-address>,ra-only" so that the ManagedFlag will be off in the RA packets for stateless operation.
OK, how does that sound? Everyone comfortable with that?
Another thing is that I plan to add a test such that if the radvd executable is not valid, the dnsmasqRA=1.
As I was doing this, I also looked through the libvirt.spec file. My, what a wonderful example of wizardly that is. Anyway, I thought some updates may be in ortder:
- increase the minimum version for dnsmasq from 2.41 to 2.48.
- why is radvd required for rpmbuild?
- in light of my patch, make radvd an optional runtime requirement. I am not a spec file expert by any means but there must be a way to not require radvd if dnsmasq >- 2.63.
Comments?
Gene
I'm still not thrilled that you're pushing forward with requiring 2.63 + a few patches backported from 2.64 into 2.63 and only checking against 2.63.
I assume you are talking about dhcpv6 and not radvd. Thus, your concerns are related to, if dnsmasq's version => 2.63, then use dnsmasq to support both statefull (ManagedFlag on) and stateless (ManagedFlag off) IPv6.
DHCPv6 does work in dnsmasq-2.63 but not very well with respect to libvirt. Libvirt plus my patch to add interface= will allow one DHCPv6 dnsmasq. With the two patches, everything works as it should.
If you do not specify any dhcp-range= or dhcp-host= parameters, then it does not matter and everything works as it should. If you do specify them, then you will (at best) get some indication with a message to syslog and, at worst, nothing happens and DHCPv6 requests are ignored.
The good news is that I have gotten the attention of dnsmasq's Fedora maintainer and he is looking into it. I expect an update for Fedora "real soon now" and, since Simon said that dnsmasq-2.64 should be available "real soon now," that 2.64 be added to F18 updates sooner rather than later.
There are currently NO checks as far as the DHCPv6 implementing code. If you specify dhcp-range or dhcp-host, the parameters will be passed to dnsmasq. I could add a check, and if the dnsmasq is earlier than 2.63, to fail dnsmasq startup. I could also issue a warning message is dnsmasq is 2.63. I have not done that because, if you do NOT specify dhcp-range and/or dhcp-host, nothing will happen and things work as they do now.
I noticed that your email has @gentoo,org. I had a fleeting look at gentoo a bunch of years ago. I do not know what problems result in your concern.
Gene
I hardly see what me having any involvement in Gentoo has anything to do with this short of saying Gentoo isn't for everyone, just as Debian, Ubuntu, Fedora, or SuSE aren't for everyone and Gentoo wasn't your cup of tea. My point is if you're going to add a check for 2.63 but really require 2.63 + 3 patches that Fedora has backported into their 2.63 version which was your original proposal, this would cause lots of headaches for every other distro out there unless they backported those very same patches into 2.63. So better to wait for 2.64 and go forward from there. libvirt works on and targets many more systems than Fedora. -- Doug Goldstein
On 11/08/2012 08:26 AM, Doug Goldstein wrote:
I'm still not thrilled that you're pushing forward with requiring 2.63 + a few patches backported from 2.64 into 2.63 and only checking against 2.63.
My point is if you're going to add a check for 2.63 but really require 2.63 + 3 patches that Fedora has backported into their 2.63 version which was your original proposal, this would cause lots of headaches for every other distro out there unless they backported those very same patches into 2.63. So better to wait for 2.64 and go forward from there. libvirt works on and targets many more systems than Fedora.
Agreed. Upstream, libvirt should require 2.64. If Fedora (or any other distro) cares about shipping 2.63 + patches, then they can also patch their backport of libvirt to relax things to 2.63. But upstream cannot assume that 2.63 is patched. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 11/08/2012 01:55 PM, Eric Blake wrote:
I'm still not thrilled that you're pushing forward with requiring 2.63 + a few patches backported from 2.64 into 2.63 and only checking against 2.63. My point is if you're going to add a check for 2.63 but really require 2.63 + 3 patches that Fedora has backported into their 2.63 version which was your original proposal, this would cause lots of headaches for every other distro out there unless they backported those very same patches into 2.63. So better to wait for 2.64 and go forward from there. libvirt works on and targets many more systems than Fedora. Agreed. Upstream, libvirt should require 2.64. If Fedora (or any other distro) cares about shipping 2.63 + patches, then they can also patch
On 11/08/2012 08:26 AM, Doug Goldstein wrote: their backport of libvirt to relax things to 2.63. But upstream cannot assume that 2.63 is patched.
Really I don't think that *anybody* should. There's no way to verify that it's true.
On 11/08/2012 01:55 PM, Eric Blake wrote:
I'm still not thrilled that you're pushing forward with requiring 2.63 + a few patches backported from 2.64 into 2.63 and only checking against 2.63. My point is if you're going to add a check for 2.63 but really require 2.63 + 3 patches that Fedora has backported into their 2.63 version which was your original proposal, this would cause lots of headaches for every other distro out there unless they backported those very same patches into 2.63. So better to wait for 2.64 and go forward from there. libvirt works on and targets many more systems than Fedora. Agreed. Upstream, libvirt should require 2.64. If Fedora (or any other distro) cares about shipping 2.63 + patches, then they can also patch
On 11/08/2012 08:26 AM, Doug Goldstein wrote: their backport of libvirt to relax things to 2.63. But upstream cannot assume that 2.63 is patched.
Understood ... I think. 1. For RADVD, if dnsmasq version => 2.63, then dnsmasq will handle the RA service. Otherwise, it will be radvd. My submitted patches implement that. Granted, the patches are, more or less, chained together and that will make life difficult. 2. Currently, there are NO version checks in the DHCP6 implementation (all DHCPv6 stuff is in one patch file currently v6-7). If I understand you correctly, you want dnsmasq version checks performed. Some of this is simple and some is not so simple. 2a. If the dsnmasq version is => 2.64, all the DHCPv6 stuff is OK. This check is fairly easy to do and I will try to get an implementation in today so that things might move along. I would like to see this as a minimum since I had modified and added to the tests performed. Pulling a piece out of the middle will be "difficult." 2b. If dnsmasq version is <=2.63, then ?? -- fail/error out the dnsmasq startup because the xml specification is invalid. -- or, just ignore the any DHCPv6 dhcp-range or dhcp-host specifications but issue a syslog warning message that it is being ignored because of the dnsmasq version. -- or ? ... any suggestions? 3. I would like to make it "easy" for any system administratiors or system maintainers who want DHCPv6 but also need to keep dnsmasq 2.63. It it is too difficult, they will simply use dnsmasq 2.64test or 2.64rc or 2.64 ... unlike libvirt, it only takes about 15 seconds to rebuild the dnsmasq rpms. At some point in time in the not so distant future, this becomes a non-issue ... it is the transition period. 3a. Do nothing! Screw it. If someone wants DHCPv6 support, then they can get some version of dnsmasq 2.64 since it will be here "real soon now". It has always been my contention that if someone wants libvirt with DHCPV6 support, they can got the little extra to get a dnsmasq that supports it. 3b. Add a configuration/compile-time options allowing 2.63. Right now I am inclined to do 3a. But, the question I have is what to do for 2b. The simplest way (and this is my inclination for today) is to error out. Right now I feel a little pressured because I am going to be unavailable for the next week to ten days. Gene
On 11/08/2012 02:30 PM, Gene Czarcinski wrote:
On 11/08/2012 01:55 PM, Eric Blake wrote:
I'm still not thrilled that you're pushing forward with requiring 2.63 + a few patches backported from 2.64 into 2.63 and only checking against 2.63. My point is if you're going to add a check for 2.63 but really require 2.63 + 3 patches that Fedora has backported into their 2.63 version which was your original proposal, this would cause lots of headaches for every other distro out there unless they backported those very same patches into 2.63. So better to wait for 2.64 and go forward from there. libvirt works on and targets many more systems than Fedora. Agreed. Upstream, libvirt should require 2.64. If Fedora (or any other distro) cares about shipping 2.63 + patches, then they can also patch
On 11/08/2012 08:26 AM, Doug Goldstein wrote: their backport of libvirt to relax things to 2.63. But upstream cannot assume that 2.63 is patched.
Understood ... I think.
1. For RADVD, if dnsmasq version => 2.63, then dnsmasq will handle the RA service. Otherwise, it will be radvd. My submitted patches implement that. Granted, the patches are, more or less, chained together and that will make life difficult.
2. Currently, there are NO version checks in the DHCP6 implementation (all DHCPv6 stuff is in one patch file currently v6-7). If I understand you correctly, you want dnsmasq version checks performed. Some of this is simple and some is not so simple.
2a. If the dsnmasq version is => 2.64, all the DHCPv6 stuff is OK. This check is fairly easy to do and I will try to get an implementation in today so that things might move along. I would like to see this as a minimum since I had modified and added to the tests performed. Pulling a piece out of the middle will be "difficult."
2b. If dnsmasq version is <=2.63, then ??
-- fail/error out the dnsmasq startup because the xml specification is invalid.
-- or, just ignore the any DHCPv6 dhcp-range or dhcp-host specifications but issue a syslog warning message that it is being ignored because of the dnsmasq version.
Since they are explicitly asking for this functionality, it's better to log an error and fail the network start. This will alert them that they aren't getting what they asked for in a very prominent manner.
-- or ? ... any suggestions?
3. I would like to make it "easy" for any system administratiors or system maintainers who want DHCPv6 but also need to keep dnsmasq 2.63. It it is too difficult, they will simply use dnsmasq 2.64test or 2.64rc or 2.64 ... unlike libvirt, it only takes about 15 seconds to rebuild the dnsmasq rpms. At some point in time in the not so distant future, this becomes a non-issue ... it is the transition period.
3a. Do nothing! Screw it. If someone wants DHCPv6 support, then they can get some version of dnsmasq 2.64 since it will be here "real soon now". It has always been my contention that if someone wants libvirt with DHCPV6 support, they can got the little extra to get a dnsmasq that supports it.
3b. Add a configuration/compile-time options allowing 2.63.
Right now I am inclined to do 3a.
I agree. If you need 2.64 for proper DHCPv6 support, then just require that. Anybody who can upgrade to 2.63 can upgrade to 2.64 (my guess is that Fedora is unique in having 2.63 as its official version for any release, and that's only for F17 (it seems reasonable that we could get dnsmasq for F18 upgraded to 2.64, maybe even F17, with appropriate testing (and depending on the adventurousness index of the new Fedora dnsmasq maintainer :-)
But, the question I have is what to do for 2b. The simplest way (and this is my inclination for today) is to error out.
I agree with that as well.
Right now I feel a little pressured because I am going to be unavailable for the next week to ten days.
On 11/08/2012 02:59 PM, Laine Stump wrote:
On 11/08/2012 02:30 PM, Gene Czarcinski wrote:
On 11/08/2012 01:55 PM, Eric Blake wrote:
I'm still not thrilled that you're pushing forward with requiring 2.63 + a few patches backported from 2.64 into 2.63 and only checking against 2.63. My point is if you're going to add a check for 2.63 but really require 2.63 + 3 patches that Fedora has backported into their 2.63 version which was your original proposal, this would cause lots of headaches for every other distro out there unless they backported those very same patches into 2.63. So better to wait for 2.64 and go forward from there. libvirt works on and targets many more systems than Fedora. Agreed. Upstream, libvirt should require 2.64. If Fedora (or any other distro) cares about shipping 2.63 + patches, then they can also patch
On 11/08/2012 08:26 AM, Doug Goldstein wrote: their backport of libvirt to relax things to 2.63. But upstream cannot assume that 2.63 is patched.
Understood ... I think.
1. For RADVD, if dnsmasq version => 2.63, then dnsmasq will handle the RA service. Otherwise, it will be radvd. My submitted patches implement that. Granted, the patches are, more or less, chained together and that will make life difficult.
2. Currently, there are NO version checks in the DHCP6 implementation (all DHCPv6 stuff is in one patch file currently v6-7). If I understand you correctly, you want dnsmasq version checks performed. Some of this is simple and some is not so simple.
2a. If the dsnmasq version is => 2.64, all the DHCPv6 stuff is OK. This check is fairly easy to do and I will try to get an implementation in today so that things might move along. I would like to see this as a minimum since I had modified and added to the tests performed. Pulling a piece out of the middle will be "difficult."
2b. If dnsmasq version is <=2.63, then ??
-- fail/error out the dnsmasq startup because the xml specification is invalid.
-- or, just ignore the any DHCPv6 dhcp-range or dhcp-host specifications but issue a syslog warning message that it is being ignored because of the dnsmasq version. Since they are explicitly asking for this functionality, it's better to log an error and fail the network start. This will alert them that they aren't getting what they asked for in a very prominent manner.
-- or ? ... any suggestions?
3. I would like to make it "easy" for any system administratiors or system maintainers who want DHCPv6 but also need to keep dnsmasq 2.63. It it is too difficult, they will simply use dnsmasq 2.64test or 2.64rc or 2.64 ... unlike libvirt, it only takes about 15 seconds to rebuild the dnsmasq rpms. At some point in time in the not so distant future, this becomes a non-issue ... it is the transition period.
3a. Do nothing! Screw it. If someone wants DHCPv6 support, then they can get some version of dnsmasq 2.64 since it will be here "real soon now". It has always been my contention that if someone wants libvirt with DHCPV6 support, they can got the little extra to get a dnsmasq that supports it.
3b. Add a configuration/compile-time options allowing 2.63.
Right now I am inclined to do 3a. I agree. If you need 2.64 for proper DHCPv6 support, then just require that. Anybody who can upgrade to 2.63 can upgrade to 2.64 (my guess is that Fedora is unique in having 2.63 as its official version for any release, and that's only for F17 (it seems reasonable that we could get dnsmasq for F18 upgraded to 2.64, maybe even F17, with appropriate testing (and depending on the adventurousness index of the new Fedora dnsmasq maintainer :-)
OK, it is done ... now I just have to rework the submitted patches: dnsmasq-RA >-2.63, otherwise radvd. DHCPv6 dnsmasq >=2.64 and error out if not. .. it only took a few lines of code.
But, the question I have is what to do for 2b. The simplest way (and this is my inclination for today) is to error out. I agree with that as well.
Right now I feel a little pressured because I am going to be unavailable for the next week to ten days.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Gene Czarcinski wrote:
I have a working patch to have dnsmasq support RA instead of radvd. However, something has come up and it will be a week to ten days before I can get it in shape to submit.
The current patch has three variables added to the _virNetworkObj structure: dnsmasqRA flag and both major and minor values for the dnsmasq's version.
I use "dnsmasq --version" and then parse out the major/minor version values. If major>2, then dnamsqFA=1. If major=2 and minor>=63, then dnsmasqRA=1. For all other cases, dnsmasqRA=0.
Code is added to the radvd functions which checks dnsmasqRA and exits if it is 1.
Code is added to the dnsmasq configuration file if dnsmasqRa=1. If dhcp-range or dhcp-hosts is specified for IPv6, then enable-ra is added for stateful (dhcpv6). Otherwise, a special "dhcp-range=<ipv6-subnet-address>,ra-only" so that the ManagedFlag will be off in the RA packets for stateless operation.
OK, how does that sound? Everyone comfortable with that?
Another thing is that I plan to add a test such that if the radvd executable is not valid, the dnsmasqRA=1.
As I was doing this, I also looked through the libvirt.spec file. My, what a wonderful example of wizardly that is. Anyway, I thought some updates may be in ortder:
- increase the minimum version for dnsmasq from 2.41 to 2.48.
The SLE11 code stream, which will be active for quite some years, has version 2.45 :(. Why is 2.48 needed? The feature you are after is in 2.63 right? Regards, Jim
- why is radvd required for rpmbuild?
- in light of my patch, make radvd an optional runtime requirement. I am not a spec file expert by any means but there must be a way to not require radvd if dnsmasq >- 2.63.
Comments?
Gene
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (5)
-
Doug Goldstein -
Eric Blake -
Gene Czarcinski -
Jim Fehlig -
Laine Stump