From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
Description of problem:
Firewall settings of Red Hat Linux 7.2 are very restrictive. At firewall
security levels "medium" and "high", port #123, which is the NTP default
port, is blocked. "dateconfig" does not enable port #123 when "Enable
Network Time Protocol" is selected.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Launch "dateconfig"
2. Checkmark "Enable Network Time Protocol" and enter the name of some
suitable time server.
3. Hit "Ok".
Actual Results: NTP should work ... .
Expected Results: It doesn't work nor does "ntpdate" allow to synchronize
the system clock (the latter after stopping "ntpd" of course).
1. NTP used to work on Roswell 2 with firewall security level "medium".
2. After enabling port #123 manually, NTP works properly.
There never was any code in dataconfig to open any ports, so are you sure that
Roswell 2 allowed access to port 123 with a firewall setting of "Medium"?
But yes, you are right that dateconfig doesn't modify the firewall settings.
Other config tools are the same way, such as serviceconf.
"dateconfig" certainly never modified any port settings, but before the advent
of Red Hat Linux 7.2, this was simply not necessary, because basic services such
as incoming "ssh" or NTP worked as of Roswell 2 and earlier when firewall level
"medium" was chosen. Now, one has the choice between having no firewall at all,
which is certainly no good idea (!), and having to tweak individual ports when
firewall levels "medium" or "high" are chosen. Under these circumstances,
"dateconfig" -should- enable port #123. Otherwise, the innocent user, having
checkmarked "Enable Network Time Protocol" is wondering, why NTP does not work,
which is not surprising as it cannot query any remote time server! According to
my observations, the firewall settings of Red Hat Linux 7.2 are much more severe
than before, thus blocking essential system services. As a consequence, the Red
Hat system configuration tools should take this into account when setting up
It may be true that the "Medium" firewall settings for 7.2 are more strict than
7.1. I can't say for sure.
I do agree that it would be nice for the config tools to be able to detect if
the services they are configuring are blocked by the firewall rules. However,
this would require that we have a nice way to query the firewall rules, which we
don't currently have. If the user has made customized firewall rules, then
trying to figure out which ports are blocked and which aren't can get
complicated very quickly. This type of call need to be in a library so that
each config tool doesn't have to implement this separately.
In other words, it requires more work than we can do at the moment.
As for the default firewall rules changing, anaconda just calls 'gnome-lokkit
--medium' to set the security level. If the settings have changed between 7.1
and 7.2, then the gnome-lokkit maintainer will know. Changing components to
I have the same complaint. If you're going to have a friendly checkbox, it
should work. At least, it should test the port and pop up a warning. Otherwise
this friendly GUI checkbox for enabling ntp just leads the user down the wrong
path, and wastes (not saves) time.
I enabled the checkbox and got in the log:
Apr 17 08:25:17 hardhat ntpd: ntpd 4.1.0 Wed Sep 5 06:54:30 EDT 2001 (1)
Apr 17 08:25:17 hardhat ntpd: ntpd startup succeeded
Apr 17 08:25:17 hardhat ntpd: precision = 18 usec
Apr 17 08:25:17 hardhat ntpd: kernel time discipline status 0040
Apr 17 08:25:17 hardhat ntpd: getnetnum: "time.nist.gov" invalid host
number, line ignored
Apr 17 08:25:17 hardhat ntpd: Un-parsable frequency in /etc/ntp/drift
Apr 17 08:25:17 hardhat ntpd: bind() fd 9, family 2, port 123, addr
184.108.40.206, in_classd=1 flags=0 fails: Address already in use
Apr 17 08:25:17 hardhat ntpd: ...multicast address 220.127.116.11 using
This is done by the ntp script now. Should be working.