Bug 133668

Summary:	ntpd configuration and pool.ntp.org
Product:	[Fedora] Fedora	Reporter:	Michal Jaegermann <michal>
Component:	system-config-date	Assignee:	Nils Philippsen <nphilipp>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-28 14:58:21 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:

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
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 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.