Bug 138133 - NTP Script takes excessive time to run on a firewall
NTP Script takes excessive time to run on a firewall
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ntp (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Brian Brock
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-04 16:30 EST by Roland Pope
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2007-0414
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-11 14:51:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Roland Pope 2004-11-04 16:30:16 EST
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:
Comment 2 RHEL Product and Program Management 2006-12-16 17:00:50 EST
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 
Comment 3 Roland Pope 2006-12-17 02:46:02 EST
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.
Comment 4 Daniel Riek 2007-01-08 20:38:07 EST
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.
Comment 5 Roland Pope 2007-01-08 21:37:59 EST
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.
Comment 12 Red Hat Bugzilla 2007-06-11 14:51:47 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 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

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