Bug 651032 - rebase netcf for RHEL6.1
rebase netcf for RHEL6.1
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: netcf (Show other bugs)
6.0
Unspecified Unspecified
low Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
: Rebase
Depends On:
Blocks: 616060 629206 633346
  Show dependency treegraph
 
Reported: 2010-11-08 12:15 EST by Laine Stump
Modified: 2011-05-19 09:43 EDT (History)
3 users (show)

See Also:
Fixed In Version: netcf-0.1.7-1.el6
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
The new/rebased version of netcf in this release of RHEL has 3 main purposes: 1) Pull in patches already carried against RHEL for netcf to simplify maintenance. 2) Lock down the version of gnulib used for building, so that a build of the netcf srpm from source will be guaranteed to be using *exactly* the same source as is used for the officially distributed RHEL binary of netcf. 3) Remove the code in netcf that examines the iptables configuration and optionally adds a rule to bypass filtering on bridge devices. This was deemed appropriate for 3 reasons: a) The additional iptables rule: -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT is only necessary if the kernel tunable: net.bridge.bridge-nf-call-iptables is set to 1, but the default for that tunable is 0 (ie the extra rule isn't needed), and if someone has changed the tunable, they surely did it for a purpose, and netcf unceremoniously adding the rule will defeat that purpose. b) Adding rules to the firewall is a policy decision, which is beyond the scope of what netcf should do. c) The code in netcf that read the iptables config was prone to error, and the majority of cases where netcf was unable to properly initialize were caused by the failure of this code; removing it makes netcf more reliable. A user who has not modified the default setting of net.bridge.bridge-nf-call-iptables will not see any operational change when running ncftool, or libvirt/virt-manager (the only current consumers of netcf). Similarly, even users who *have* changed net.bridge.bridge-nf-call-iptables to 1, but have previously run ncftool or libvirt at least once, will also not see any operational change, as the extra iptables rule will have already been added (and once there, it persists across system reboots).
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 09:43:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Laine Stump 2010-11-08 12:15:21 EST
RHEL 6.0's netcf is netcf-0.1.6 plus several patches. netcf-0.1.7 simply has these patches, plus two others that came in after the 6.0 window was closed.

 Commit 210b78b375b525bdc4af952810e318c24f47cbd1
 Remove code that modifies iptables config for bridges

 (This code has been the source of the majority of bug reports against netcf,
 and after discussion, we've decided that netcf isn't the proper place for this functionality anyway)

 Commit fde184ad4b69a111ea89f4ae7fc7abeb16c94436
 Register gnulib as a proper submodule

 (this will ensure that any build of netcf from source will use *exactly* the
 same gnulib source, rather than just whatever is the latest available from git)

There are also 3 other patches that are directly related to these two, and no other changes.

Rather than carry patches against upstream netcf, it would simplify maintenance to just rebase.
Comment 3 Laine Stump 2010-11-12 15:47:34 EST
The rebased version is nearly equivalent to the current 0.1.6 + patches already in RHEL6. The two meaningful changes that *aren't* already in RHEL6 are the ones listed in the original comment. 

The first patch will only change operation if the kernel tunable parameter net.bridge.bridge-nf-call-iptables has been changed to 1 from its default of 0. In this case, while netcf previously would do one of two things:

1) refuse to start due to problems encountered while trying to read the current iptables config (this was the source of many bugs reported against netcf)

2) check for the presence of the following rule in the iptables config:

     -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT 

and add it if it's not found (this rule is required to have unfettered traffic flow across the bridge without any additional iptables rules).

The 2nd change (making gnulib a proper git submodule) will have no visible effect whatsoever, except that the gnulib version in use for the build will be locked down, so that future official netcf builds, as well as builds from srpms will reliably and accurately use *exactly* the same source as builds now (without this change, new builds will use whatever is the most recent contents of gnulib git, which is obviously undesirable.

Change in testing related to removing iptables examination/modification code
----------------------------------------------------------------------------

This test *can* be added (although all it really does is to verify that the newer version of netcf is being used, since it's testing for the *absence* of a behavior, and that can just as easily be done by examining the version of the installed package):

1) start with a fresh install of RHEL (not updated from a previous release)

2) start libvirt with the default config (if it's not already running), to ensure there is at least one bridge up and running.

2) in /etc/sysctl.conf, change net.bridge.bridge-nf-call-iptables to 1.

3) run "sysconfig -p" to enable this new setting.

4) run "iptables -S" and verify that this rule is *not* present in the output:

     -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT 

5) run "ncftool" and verify you get the "ncftool>" prompt

6) Again run "iptables -S" and verify that the above rule is still not present in the output.

The main change in testing related to this change in code is that you can expect less failures of netcf to initialize.

Changes in testing related to making gnulib a proper submodule
--------------------------------------------------------------

This has 0 effect on operation, and has no new testing related to it.
Comment 4 Laine Stump 2010-11-12 15:47:34 EST
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The new/rebased version of netcf in this release of RHEL has 3 main purposes:

1) Pull in patches already carried against RHEL for netcf to simplify maintenance.

2) Lock down the version of gnulib used for building, so that a build of the netcf srpm from source will be guaranteed to be using *exactly* the same source as is used for the officially distributed RHEL binary of netcf.

3) Remove the code in netcf that examines the iptables configuration and optionally adds a rule to bypass filtering on bridge devices. This was deemed appropriate for 3 reasons:

  a) The additional iptables rule:

     -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT 

is only necessary if the kernel tunable:

  net.bridge.bridge-nf-call-iptables

is set to 1, but the default for that tunable is 0 (ie the extra rule isn't needed), and if someone has changed the tunable, they surely did it for a purpose, and netcf unceremoniously adding the rule will defeat that purpose.

  b) Adding rules to the firewall is a policy decision, which is beyond the scope of what netcf should do.

  c) The code in netcf that read the iptables config was prone to error, and the majority of cases where netcf was unable to properly initialize were caused by the failure of this code; removing it makes netcf more reliable.

A user who has not modified the default setting of net.bridge.bridge-nf-call-iptables will not see any operational change when running ncftool, or libvirt/virt-manager (the only current consumers of netcf). Similarly, even users who *have* changed net.bridge.bridge-nf-call-iptables to 1, but have previously run ncftool or libvirt at least once, will also not see any operational change, as the extra iptables rule will have already been added (and once there, it persists across system reboots).
Comment 7 Laine Stump 2011-01-13 15:37:20 EST
The fix for this problem is in netcf-0.17-1, which has been built:

https://brewweb.devel.redhat.com/buildinfo?buildID=154128
Comment 11 Laine Stump 2011-01-18 01:59:45 EST
(Sorry, I had actually typed up this comment yesterday (with a lot more now unnecessary commentary about step 5), and forgot to hit "Save Changes")

There is a flaw in the test that I wrote in Comment 3 - if some other subsystem is adding this rule to iptables:

    -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT 

then step 4 will seemingly fail (as will step 6). I guess the following change needs to be made to the test:

1.5) If this rule is in /etc/sysconfig/iptables (and therefore in the output of "iptables -S"), remove it from /etc/sysconfig/iptables and reboot:

  -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT 

I'm fairly certain that once you do this, you'll find that the rule isn't re-added. (I tried it on my RHEL6 test machine, with the official netcf-0.1.7-1.el6 build, and it worked correctly).

If that's the case for you as well, please move this bug back to ON_QA.
Comment 12 zhanghaiyan 2011-01-18 02:21:40 EST
Verified PASS with netcf-0.1.7-1.el6.x86_64 according to comment 11
- 2.6.32-94.el6.x86_64

1) start with a fresh install of RHEL (not updated from a previous release)
2) start libvirt with the default config (if it's not already running), to
ensure there is at least one bridge up and running.
3) in /etc/sysctl.conf, change net.bridge.bridge-nf-call-iptables to 1.
4) run "sysconfig -p" to enable this new setting.
5) run "iptables -S" and still CAN see the following present in the output as the rule was added by the other applications or older netcf
     -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT 
6) run "ncftool" and could get the "ncftool>" prompt
7) remove the rule from /etc/sysconfig/iptables and reboot the host
8) Again run "iptables -S" and cannot see the iptables rule
Comment 13 errata-xmlrpc 2011-05-19 09:43:37 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0620.html

Note You need to log in before you can comment on or make changes to this bug.