Bug 834350 - aeolus-configure should not overwrite /etc/ntp.conf
aeolus-configure should not overwrite /etc/ntp.conf
Status: CLOSED DUPLICATE of bug 827587
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-configure (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Mike Orazi
Depends On:
  Show dependency treegraph
Reported: 2012-06-21 11:38 EDT by Matt Wagner
Modified: 2014-08-17 18:27 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-02 15:32:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matt Wagner 2012-06-21 11:38:39 EDT
Description of problem:
Aeolus has good reason to ensure that ntpd is running, because some cloud providers (notably, EC2) use include some measure of time in their cryptographic hashing, such that a seriously-inaccurate cause will cause them to fail. (Meant to prevent replay attacks, I assume.) Weird failures will ensue if your clock is considerably off.

However, the way we go about this is to overwrite the user's /etc/ntp.conf with a minimal configuration and then use puppet to ensure that NTP is running. This is broken for two reasons:

a.) If the user had manually configured ntpd previously, we erase their configuration and overwrite it with ours.

b.) The configuration file we lay down is _worse_ than the default ntp.conf that is installed by yum, which sets up security restrictions and uses multiple servers in the NTP pool, including the vendor string (e.g., 0.fedora.pool.ntp.org). Beyond the fact that we throw that away, the single entry we use -- "server pool.ntp.org" -- doesn't even work in LANs that follow NTP best practices (including our own), which is to restrict access to external NTP servers and force the use of internal servers (handed out via DHCP).

The net result of this is that, when I run aeolus-configure on a box internally, NTP *stops* working for me. It runs, but against an unreachable server. Before running aeolus-configure, it was working just fine with internal servers. (The changes I had made my hand to use more stable servers are also lost and not preserved anywhere.)

It seems like what we should do is merely instruct puppet to make sure ntpd is running, but not monkey with its configuration. In all cases, this should work at least as well as what we do now.
Comment 1 Matt Wagner 2012-07-02 15:32:27 EDT
Seems like I wasn't the first to find this: https://bugzilla.redhat.com/show_bug.cgi?id=827587

Closing as a dupe.

*** This bug has been marked as a duplicate of bug 827587 ***

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