shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-23 21:34:54 +03:00
Code Releases Activity
21d097c4e1
libvirt/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.args

263 lines
4.5 KiB
Plaintext
Raw Normal View History

network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_INP \
--in-interface virbr0 \
--protocol tcp \
--destination-port 67 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_INP \
--in-interface virbr0 \
--protocol udp \
--destination-port 67 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_OUT \
--out-interface virbr0 \
--protocol tcp \
--destination-port 68 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_OUT \
--out-interface virbr0 \
--protocol udp \
--destination-port 68 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_INP \
--in-interface virbr0 \
--protocol tcp \
--destination-port 53 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_INP \
--in-interface virbr0 \
--protocol udp \
--destination-port 53 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_OUT \
--out-interface virbr0 \
--protocol tcp \
--destination-port 53 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_OUT \
--out-interface virbr0 \
--protocol udp \
--destination-port 53 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWO \
--in-interface virbr0 \
--jump REJECT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWI \
--out-interface virbr0 \
--jump REJECT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWX \
--in-interface virbr0 \
--out-interface virbr0 \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWO \
--in-interface virbr0 \
--jump REJECT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWI \
--out-interface virbr0 \
--jump REJECT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWX \
--in-interface virbr0 \
--out-interface virbr0 \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_INP \
--in-interface virbr0 \
--protocol tcp \
--destination-port 53 \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_INP \
--in-interface virbr0 \
--protocol udp \
--destination-port 53 \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_OUT \
--out-interface virbr0 \
--protocol tcp \
--destination-port 53 \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_OUT \
--out-interface virbr0 \
--protocol udp \
--destination-port 53 \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_INP \
--in-interface virbr0 \
--protocol udp \
--destination-port 547 \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_OUT \
--out-interface virbr0 \
--protocol udp \
--destination-port 546 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWO \
--source 192.168.122.0/24 \
--in-interface virbr0 \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWI \
--destination 192.168.122.0/24 \
--out-interface virbr0 \
--match conntrack \
--ctstate ESTABLISHED,RELATED \
--jump ACCEPT
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 192.168.122.0/24 '!' \
--destination 192.168.122.0/24 \
--jump MASQUERADE
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 192.168.122.0/24 \
-p udp '!' \
--destination 192.168.122.0/24 \
--jump MASQUERADE \
--to-ports 1024-65535
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 192.168.122.0/24 \
-p tcp '!' \
--destination 192.168.122.0/24 \
--jump MASQUERADE \
--to-ports 1024-65535
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 192.168.122.0/24 \
--destination 255.255.255.255/32 \
--jump RETURN
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 192.168.122.0/24 \
--destination 224.0.0.0/24 \
--jump RETURN
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWO \
--source 2001:db8:ca2:2::/64 \
--in-interface virbr0 \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table filter \
--insert LIBVIRT_FWI \
--destination 2001:db8:ca2:2::/64 \
--out-interface virbr0 \
--match conntrack \
--ctstate ESTABLISHED,RELATED \
--jump ACCEPT
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 2001:db8:ca2:2::/64 '!' \
--destination 2001:db8:ca2:2::/64 \
--jump MASQUERADE
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 2001:db8:ca2:2::/64 \
-p udp '!' \
--destination 2001:db8:ca2:2::/64 \
--jump MASQUERADE \
--to-ports 1024-65535
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 2001:db8:ca2:2::/64 \
-p tcp '!' \
--destination 2001:db8:ca2:2::/64 \
--jump MASQUERADE \
--to-ports 1024-65535
ip6tables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table nat \
--insert LIBVIRT_PRT \
--source 2001:db8:ca2:2::/64 \
--destination ff02::/16 \
--jump RETURN
iptables \
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 03:20:53 +03:00
-w \
network: wire up support for IPv6 NAT rules Now that we have support for IPv6 in the iptables helpers, and a new option in the XML schema, we can wire up support for it in the network driver. Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-08 16:40:15 +03:00
--table mangle \
--insert LIBVIRT_PRT \
--out-interface virbr0 \
--protocol udp \
--destination-port 68 \
--jump CHECKSUM \
--checksum-fill
Copy Permalink