Bug 512206
Summary: | Disable net.bridge.bridge-nf-call-*tables by default | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mark McLoughlin <markmc> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | brunojcm, herbert.xu, ian.springer, iarlyy, jcm, jpazdziora, klaus, mishu, notting, overholt, rvokal, virt-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-07-31 13:42:36 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 498969 |
Description
Mark McLoughlin
2009-07-16 17:01:17 UTC
Thanks for your report. Bugzapper Team Member. Blah. I disagree; if we're changing the defaults for *everyone*, we should just change the kernel, rather than a configuration file that is %config(noreplace). Granted. But given that point was made and rejected on the thread, I don't see another way to proceed Came up again on qemu-devel recently: http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01592.html Any chance we get this change in? http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=af3d40e8a4293f83abe9efaf8995f28f3287c758 Will get built before Tuesday one way or another. I installed a clean x86_64 system from the F-12 beta yesterday and this was set to 1 for me. Do you have a kernel with the bridge driver modular? I'm not actually at the machine ATM and it's powered off, but it's just stock F-12 x86_64 kernel. $ lsmod | grep bridge bridge 54112 0 stp 2724 1 bridge llc 6400 2 bridge,stp 2.6.31.5-96.fc12.x86_64 Hello, I have a fresh F12 x86_64 install, running under vmware. When I run sysctl -p without touching /etc/sysctl.conf, I get # sysctl -p net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 kernel.core_uses_pid = 1 error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key error: "net.bridge.bridge-nf-call-iptables" is an unknown key error: "net.bridge.bridge-nf-call-arptables" is an unknown key # echo $? 255 # rpm -qf /etc/sysctl.conf initscripts-9.02-1.x86_64 # rpm -Vf /etc/sysctl.conf .......T. c /etc/inittab # lsmod | grep bridge # So the problem here is that the keys generate errors, not warnings, which leads to sysctl -p returning error, which has bad impact on any script which assumes that sysctl -p does not fail. I've encountered it when oracle-xe-univ installation failed on Fedora 12 because of failed pre-installation scriptlet. Should I open new bugzilla for this issue, or reopen this one? Is it even related? No, I suspect that you may just want to pass '-e'. (In reply to comment #11) > No, I suspect that you may just want to pass '-e'. Unfortunately, it's not me who packs oracle-xe-univ rpm, it's Oracle. The net effect is that the first installation attempts of Oracle XE on Fedora 12 fails, the second one passes. I'm trying to disable Netfilter processing in bridges using the sysctl.conf method (RHEL5.4), but those keys only become valid after 'bridge.ko' is insmod'ed. My set-up does not have any bridges coming up at boot time (libvirt creates them on demand), so having them disabled at boot simply doesn't work. I was thinking in forcibly insmod bridge before any network initialization so the keys will be there when init.d/network calls "sysctl -e -p /etc/sysctl.conf", but I'd like to hear how are you working around this in RAWHIDE first. Also, please take note that removing and reinserting the bridge module will always reset those keys to their default value. Please, mark https://bugzilla.redhat.com/show_bug.cgi?id=634736 as related to this bug. This one pops up more often on web search results, and doesn't point to the "current" status about this issue. |