Bug 133668 - ntpd configuration and pool.ntp.org
ntpd configuration and pool.ntp.org
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: system-config-date (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-25 19:58 EDT by Michal Jaegermann
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-28 10:58:21 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 Michal Jaegermann 2004-09-25 19:58:52 EDT
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
http://www.pool.ntp.org/

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):
system-config-date-1.7.8-1
Comment 1 Nils Philippsen 2004-09-28 10:58:21 EDT
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 12:32:29 EDT
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 11:33:58 EDT
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.