Bug 834350

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.