Remove deprecated calls of using ntpdate in favor of ntpd
Summary
ntpdate is slowly being depricated. STIG enhancements for RHEL 6 penalize systems that make use of ntpdate. Also documentation from the NSA Hardening Guidelines as well as CIS Hardening documentation recommends disabling the use of ntpd as a full-time daemon.
Owner
- Name: Michael Harris
- Email: MikeDawg (at) gmail (dot) com
- Release notes owner:
Current status
- Targeted release: Fedora 20
- Last updated: 2013-7-8
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
ntpdate is slowly being depricated in favor of ntpd. DoD STIGs now penalize for the use of ntpdate on Red Hat Enterprise systems. I would like to "modernize" the ntpdate utility to do two things.
First, I would like to get rid of the dependency of ntpdate, in favor of ntpd.
Second, I would like to add a set time and/or randomized time for ntpd to check for time updates (as configured by the user in /etc/sysconfig/ntpdate).
I'm thinking of using ntpd with the -q option to immediately exit the daemon after it runs.
Benefit to Fedora
First and foremost, it is backing away from a dependency that is set to deprecate at some point in the future. ntpd now handles many/most of the tasks that ntpdate was once used for. I'm also adding the feature of either random time checks based on a user interval, or just checks at an interval.
Scope
- Proposal owners: Need to re-engineer the startup task for ntpdate ( /etc/init.d/ntpdate, NOT /usr/sbin/ntpdate ); or figure out if this is something that is more easily created via a cron job. Format /etc/sysconfig/ntpdate to accept additional options, as discussed above.
- Other developers: None
- Release engineering: None
- Policies and guidelines: None
Upgrade/compatibility impact
No changes will be needed for the system to function as-is. In order to incorporate a (random or not) check of time will require modification of the /etc/sysconfig/ntpdate configuration file.
pwouters: ntpd at boot MUST be called and MUST allow settig the time with any offset to the proper time for those systems with failing/bad realtime clock
pwouters: if we are changing time, we should consider saving/restoring the timestmap on reboot, for systems without a realtime clock (like raspberry pi)
pwouters: See also tlsdate as alternative to obtain time
pwouters: The real time issue is that if the time is off by about 1 hour, DNSSEC will cause failures, preventing pool.ntp.org to be resolved, preventing ntpd/ntpdate from setting the time correctly
How To Test
Will need to verify that ntpd correctly launches, and is able to set the time/date. Will also need to verify the random/interval check is running. This can be easily done by parsing the info out the log files.
User Experience
Will not be noticeable to the average audience. The change will impact those that are doing various levels of security checks/tests against their systems, and more specifically, those that are using guidelines from the DoD STIGs, NSA Hardening Guidelines (currently only up to RHEL 5, however, many of the configurations still apply), and the CIS Hardening Documents.
Dependencies
Will have the continued dependency on ntpd.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) Revert to the previous configuration of continuing use of ntpdate.
- Contingency deadline: Beta Freeze
- Blocks release? No
Documentation
Nothing yet, however, will update documentation for the previously used ntpdate package.