On 11/08/2012 02:41 PM, Laine Stump wrote:
On 11/07/2012 04:25 PM, Gene Czarcinski wrote:
On 11/06/2012 11:23 AM, Gene Czarcinski wrote:
ip6tables -I FORWARD 1 -i virbr18 -o virbr18 -j ACCEPT
This one currently isn't getting added, because
networkAddGeneralIp6tablesRules() returns immediately if there are no
ipv6 addresses defined for the network.
Note that up until now, unless someone had an ipv6 address defined
for a
network, ip6tables was never called, so theoretically you could run
libvirtd without having ip6tables installed on your machine, but with
this change *all* networks would fail to start if the ip6tables binary
was missing. That *shouldn't* be a problem because (at least on
Fedora/RHEL/CentOS) it is a part of the same package as iptables, but
I've seen strange setups in the last few years - in particular I recall
one Gentoo user whose networks were mysteriously failing, and it was
because he had built the iproute package with some sort of "minimal"
configuration that's available on Gentoo, causing something or other to
fail in a mysterious way (compounded in troubleshooting by the fact
that
none of us would ever have expected such a thing).
How about a configure/compile time option for those systems which may
not have ip6tables ... the default being that ip6tables is assumed.
"ping"
Sorry, I've been overwhelmed and am churning.
OK, I have not heard a plain yes or no on this.
IPv4 and IPv6 networks are suppose to have the same (more or less)
functionality so why isn't this OK.
"Maintaining backward compatibility", both API and operational. In the
past it wasn't the case that we simply did nothing about ipv6 on
libvirt's networks, instead we explicitly set a sysctl to *disable* it.
That must have been done for some reason. That reason may no longer be
valid, but we don't know that yet (it happened before I was around). If
the reason is no longer valid, we can go ahead as you suggest (and I
would say we don't even need an option to not have ip6tables, just force
people to build the full iptables package as God intended :-P). If the
reason *is* still valid, then we need to only enable the ipv6 sysctl and
add the ip6tables rule in response to some new flag attribute in the
network config.
If you do want to give someone the option of running without
ip6tables, fine make it a compile-time option.
Actually I want to hear some historical info about why ipv6 was
explicitly *disabled* with sysctl on libvirt's networks in the past.
Maybe it's time to change that default, but I don't want to do it
lightly - it may even have been done in response to a CVE. (danpb or DV
would probably have the best insight about this. I'll point them at this
thread.)
New functionality is great, but you can't upset working systems. (I know
I'm very tedious and am sounding like a broken record, but this is a
topic that libvirt takes *very* seriously; the API must always be 100%
backward compatible, and consciously programmed behavior should always
remain the same.)
I believe it is time for someone who has the project memory to chime in
on this.
It also might be a good idea, if individuals who are knowledgeable in
distributions other than Fedora and RHEL, to add their perspective
On the other hand, while there may have been valid reasons to do this
originally, it may be continuing because "this is the way we always did
it."
Gene
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list