Bug 133668 - ntpd configuration and pool.ntp.org
Summary: ntpd configuration and pool.ntp.org
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-date (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-25 23:58 UTC by Michal Jaegermann
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-28 14:58:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2004-09-25 23:58:52 UTC
Description of problem:

Current version of ntp lists among available servers also
pool.ntp.org.  If I understand correctly how poll.ntp.org
works one is supposed to put in a configuration file
multiple servers with the same name and they will resolve
to different IP addresses not always the same. See

But if one is trying to use 'system-config-date' for that
purpose then my experiments indicate that only one entry
for poll.ntp.org can be used and moreover it gets resolved
to a fixed IP address recorded in /etc/ntp.conf and in
/etc/ntp/step-tickers in a configuration time.  This seems
to contravene the whole idea of pool.ntp.org.

Yes, I can see that punching on ntpd startup firewall holes
for ntp servers may be here troublesome.

Version-Release number of selected component (if applicable):

Comment 1 Nils Philippsen 2004-09-28 14:58:21 UTC
I've removed pool.ntp.org from the ntpservers file for now (1.7.9-1)
as s-c-date really doesn't handle multi-homed machines well.

Comment 2 Michal Jaegermann 2004-09-28 16:32:29 UTC
Don't you think that handling multi-homed servers should really
be a longer range goal and that closing this report will make
the issue "lost" in the future?

One possibilty of handling firewall issues would be to open a port
123, check which connections are really in use (proably with ntpq),
and tighten up rules to what is really required by the current
ntp configuration.  There could be a MULTIHOMED flag which informs
startup if such treatment is needed. s-c-date does need to be
"smarter" for that (and AFAICS clock.redhat.com is multi-homed
as well :-).

Comment 3 Nils Philippsen 2004-09-29 15:33:58 UTC
I fixed the immediate problem with a short-term workaround. I've
already opened bug #133925 for enhancing s-c-date accordingly some
time in the future.

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