Bug 138133
| Summary: | NTP Script takes excessive time to run on a firewall | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Roland Pope <rpope> |
| Component: | ntp | Assignee: | Miroslav Lichvar <mlichvar> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | Keywords: | Reopened |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2007-0414 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-06-11 18:51:47 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: | |||
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request. I find it a little disappointing that this buzilla has been closed with no explanation as to why anyone would want to retain the current behaviour?? If you are able to explain a good reason for running iptables from the ntp init script at all when FIREWALL_MODS="no", then I will leave this bugzilla closed. The explanation has been given internally and is only visible with a privileged Bugzill account. It is visible to the Red Hat support staff that then communicates the decision and it's reasons to the customers who reported the issue. That is part of Red Hat's support and development process. The problem now is that you reported this issue directly via Bugzilla. Bugzilla is used as a development tool and every change has to go through it. So Red Hat appreciates bug reports. There though is no SLA and thus customer issues need to go through the official support department. Only there we can ensure that decisions are reported back to the customers. Now the planning principle for RHEL updates is to limit the rate of change as every change bears the risk of regression. Product management decided that this request does not satisfy the criteria for inclusion in an update at this stage of the RHEL3 life cycle: it's impact is limited and it is possible to work-around, while RHEL 3 as a release is already in the transition from Full Support (which ended with Update 8) to the Maintenance Phase of it's lifecycle. Ok, thanks for your answer. That being said, I would say that no longer redundantly running 'iptables -L' would be more of a fix for a fairly benign bug rather than the introduction of a potential regression fault. If you look in the script, it does nothing with the captured output of the iptables list when FIREWALL_MODS="no", so putting an 'if [ !FIREWALL_MODS == 'no' ]' conditional around the running of 'iptables -L' would be a logical solution. I incidentally have a support contract for RHEL3, however, I chose (perhaps erroneously), to log the bugzilla so it was in the public forum for other users to see. It did surprise me that it took close to 2 years for anyone to respond, as I had previously considered bugzilla an appropriate avenue to logs faults against RedHat systems. Such long response times, only to be followed up with a 'Closed for undisclosed reasons' leads me to wounder about the RedHat processes around dealing with bugzilla entries. 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 the 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-2007-0414.html |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: When running ntpd on a firewall with a lot of custom rule chains, the ntp init script takes ages to execute. This happens because of the initial 'if iptables -L -n 2>/dev/null | grep -q RH-Firewall-1- INPUT ; then ...' which is not bypassed by FIREWALL_MODS="no" in /etc/sysconfig/ntp. The ntpd init script need to be modified to not do anything with iptables at all when FIREWALL_MODS="no". Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create loads of iptables rules and custom chains 2. run 'service ntpd status' 3. wait for ages for command to return Actual Results: The script eventually comes back, but it can take a long time on a slow machine with 6 interfaces and more than 100,000 firewall rules! Expected Results: You should be able to override the run of iptables -L by setting FIREWALL_MODS="no" in /etc/sysconfig/ntp Additional info: