chrony

Overview

chrony is the upstream package that provides tools for time synchronisation using the Network Time Protocol (NTP). The project includes the chronyd daemon and the chronyc command-line client. It can synchronise the system clock with NTP servers, reference clocks, and local manual input, and it can also act as an NTP server or peer for other machines on the network. (chrony-project.org)

In a Linux distribution, this package is typically used wherever accurate timekeeping matters for system logging, scheduled jobs, authentication flows, distributed services, or any software that depends on a reasonably stable clock. NiceOS packages it so the daemon, client, configuration files, and service integration can be managed in a distribution-friendly way. This statement about distribution role is an inference from the upstream project purpose and should be verified by NiceOS maintainers if the packaging layout changes. (chrony-project.org)

Purpose and typical use cases

Typical use cases include:

• synchronising a workstation or server clock with public or private NTP sources;
• keeping virtual machines and intermittently connected systems in sync;
• providing an internal time service to other systems on the same network;
• monitoring time synchronisation status from the local machine with chronyc.

Typical users include:

• system administrators who need reliable time synchronisation on servers and infrastructure nodes;
• developers who want predictable timestamps during testing and debugging;
• CI/CD and automation maintainers who need clocks that do not drift excessively during builds or test runs;
• security and identity engineers who depend on time being consistent for logs, certificates, or related workflows.

These are practical use cases inferred from the upstream documentation and common deployment patterns; NiceOS maintainers should verify any environment-specific assumptions before relying on them. (chrony-project.org)

Upstream project

The upstream project is maintained as chrony and its official documentation describes it as a versatile implementation of NTP. The project site provides the main introduction, documentation, FAQ, and download/release information. The upstream repository is linked from the project download page. (chrony-project.org)

Dist-git repository contents

This dist-git repository is organized to keep packaging metadata separate from upstream source material:

• SPECS/ — RPM spec files and package policy;
• SOURCES/ — source manifests and related metadata used to describe external inputs;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, if present for this package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. This keeps the repository lightweight and makes it easier to review packaging changes without carrying large binary blobs in Git. The exact manifest format and any repository-specific conventions should be verified by NiceOS maintainers if they differ from other packages. (chrony-project.org)

Source storage and integrity policy

For this package, the expected workflow is:

1. keep upstream source archives outside the Git history;
2. record the approved source inputs in SOURCES/ manifests;
3. review manifest changes whenever upstream tarballs, signatures, or vendored inputs change;
4. rebuild from the tracked sources rather than from unreviewed local copies.

When updating the package, do not rely on manual file drops into the repository. Check that the manifest still points to the intended upstream release material, and confirm that the packaging metadata still matches the imported source set. If NiceOS uses additional verification steps such as signature checks or separate policy files, maintainers should apply those as part of the update review. (chrony-project.org)

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream release notes or documentation mention changes in configuration, defaults, or supported platforms;
• whether the spec file needs adjustments for new or removed build-time options;
• whether any patch set still applies cleanly and remains necessary;
• whether SOURCES/ manifests need regeneration because the upstream source input changed;
• whether SBOM/ material needs to be refreshed if NiceOS tracks bill-of-materials data for this package;
• whether service files, config file paths, or helper scripts need review after the upstream update.

Risks to consider:

• time synchronisation changes can affect service startup order or dependent infrastructure;
• configuration drift may break expected daemon behaviour after an upgrade;
• packaging changes may require manual review if upstream reorganises files or build options;
• any local policy around permissions, sockets, or service integration should be rechecked after update.

If any of these points are unclear from the package metadata alone, NiceOS maintainers should verify them before relying on the update. (chrony-project.org)

Build and verification checklist

Use this checklist when preparing an RPM update:

• confirm that the upstream source referenced by SOURCES/ is the intended one;
• review the spec file for obsolete patches, build flags, and file lists;
• verify that the package still builds cleanly in the target NiceOS build environment;
• check that installed files land in the expected locations;
• review the daemon, client, and configuration packaging for consistency;
• run the relevant package tests or smoke checks available in the build environment;
• verify that the generated RPM metadata matches the packaging policy;
• inspect the resulting service and configuration behaviour on a test system if the package affects runtime time synchronisation.

A minimal functional check is to ensure the daemon starts, the client can query status locally, and the package installs without unresolved file or dependency issues. The exact test commands depend on NiceOS policy and should be documented in the spec or package workflow if they are standardized. (chrony-project.org)

References

• chrony project introduction
• chrony documentation
• chrony FAQ
• chrony downloads
• chronyd(8) manual page
• chronyc(1) manual page

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/chrony
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.