Deployment · Linux and System Administration
Deploy Server Time Synchronization with Chrony
Accurate time underpins Kerberos, certificate validity and event correlation. Chrony measures sources and disciplines the system clock. Timezone controls presentation and is not a…
Technical review:
Architecture and operating model
Accurate time underpins Kerberos, certificate validity and event correlation. Chrony measures sources and disciplines the system clock. Timezone controls presentation and is not a substitute for synchronization.
Identify approved NTP sources, network access and VM host/guest clock mechanisms first. Avoid two independent daemons controlling the same clock. Verify distribution-specific service names/config paths, configure sources with iburst and inspect service state.
Sudden forward/backward steps can affect databases, certificates and schedulers. Limit makestep conditions to the intended startup window; assess maintenance impact before runtime steps. Distinguish source reachability from trusted synchronization.
- 1Approved time source
- 2Chrony measurement
- 3Clock correction
- 4Offset/source alerts
Design parameters
- Source diversity
- Assess whether multiple addresses share one physical time source.
- Offset/skew
- Monitor offset, jitter and frequency over time rather than one sample.
- VM clock path
- Check supported coexistence of guest tools and NTP.
Worked example
With three approved sources, inspect the selected source using chronyc sources -v and system correction using tracking. Remove one source and observe reselection. If the target is 50 ms, validate it over 24 hours rather than one initial sample.
Example commands: replace lab values and confirm permissions and software versions before use.
chronyc tracking
chronyc sources -v
chronyc sourcestats -v
# Configuration fragment, replace with approved reachable sources:
# server ntp1.example.test iburst
# server ntp2.example.test iburst
# makestep 1.0 3Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Reach is zero | UDP 123, resolver or source reachability. | Check source DNS and network rules. |
| Clock looks correct but unsynchronized | Manual clock or local mode. | Inspect tracking reference and leap status. |
Acceptance checks
- Verify a single clock manager.
- Configure approved sources.
- Record tracking/sources output.
- Test source outage.
- Assess clock-step impact.
- Define offset alerts.
Related concepts
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
TLS and certificate validation
TLS protects confidentiality and integrity in transit; certificate validation helps verify the peer’s identity. Evaluate names, chains, validity periods and trusted roots together. Encryption does not prove correct application authorization. If a reverse proxy or inspection device is used, show where TLS terminates. Disabling validation is not a permanent troubleshooting solution: investigate hostname mismatch, missing intermediate certificates and incorrect device clocks separately.
Application consistency
A copy that boots does not prove application-data consistency. Operating-system caches, database logs and write ordering across disks or services affect the result. A crash-consistent copy resembles recovery after an unexpected shutdown; an application-consistent copy follows supported application preparation and write coordination. Validate transaction integrity, relationships between records and application behaviour after recovery, rather than only counting files. Confirm backup integration, application version and reported errors before assuming that consistency was achieved.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.