From Fedora Project Wiki
< Changes
(Not approved for F20 by FESCo due to owner unresponsiveness) |
|||
| (19 intermediate revisions by 3 users not shown) | |||
| Line 20: | Line 20: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= | = Remove deprecated calls of using ntpdate in favor of ntpd <!-- The name of your change proposal --> = | ||
== Summary == | == Summary == | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | ||
ntpdate is slowly being depricated. STIG enhancements for RHEL 6 penalize systems that make use of ntpdate. | 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 == | == Owner == | ||
| Line 33: | Line 33: | ||
* Name: [[User:Mikedawg| Michael Harris]] | * Name: [[User:Mikedawg| Michael Harris]] | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: MikeDawg | * Email: MikeDawg (at) gmail (dot) com | ||
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
| Line 40: | Line 40: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/20 | Fedora 20 ]] | ||
* Last updated: 2013-7-8 | * Last updated: 2013-7-8 | ||
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | ||
| Line 58: | Line 58: | ||
First, I would like to get rid of the dependency of ntpdate, in favor of ntpd. | 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 for ntpd to check for time updates (as configured by the user in /etc/sysconfig/ntpdate). | 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 == | == Benefit to Fedora == | ||
| Line 66: | Line 68: | ||
== Scope == | == Scope == | ||
<!-- What work do the developers have to accomplish to complete the change in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the developers have to accomplish to complete the change in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* 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. | |||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Other developers: | * Other developers: None <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Release engineering: | * Release engineering: None <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | ||
* Policies and guidelines: | * Policies and guidelines: None <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | ||
| Line 84: | Line 86: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
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. | 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 == | == How To Test == | ||
| Line 101: | Line 111: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
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 == | == User Experience == | ||
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
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 == | == Dependencies == | ||
| Line 112: | Line 122: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Will have the continued dependency on ntpd. | |||
== Contingency Plan == | == Contingency Plan == | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: (What to do? Who will do it?) | * Contingency mechanism: (What to do? Who will do it?) Revert to the previous configuration of continuing use of ntpdate. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: | * Contingency deadline: Beta Freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? | * Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== Documentation == | == Documentation == | ||
| Line 126: | Line 136: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Nothing yet, however, will update documentation for the previously used ntpdate package. | |||
== Release Notes == | == Release Notes == | ||
Latest revision as of 18:36, 13 August 2013
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.