Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd/timeinit: add HTTPS time synchronisation service #2360

Merged
1 commit merged into from
Dec 1, 2021

Conversation

markcorbinuk
Copy link
Contributor

@markcorbinuk markcorbinuk commented Oct 27, 2021

Add a new timesync-https systemd service to synchronise the system time at boot using an HTTPS header. The service uses curl to request an HTTPS header from either $API_ENDPOINT/connectivity-check (default) or the URL defined by the os.network.connectivity.uri field in config.json. The URL used must return HTTP code 204 (No Content) in response to a request so that we can determine that we have full network connectivity and are not operating behind a captive portal.

The date field returned by a valid header is used to set the current system time. The date/time derived from the header is assumed to be a reasonable source of 'truth' such that it can be used to adjust the system time both backwards and forwards. This will compensate for any erroneous timestamps saved via fake-hwclock or any invalid data read from an RTC.

The service will exit when a valid response has been received. Poll attempts will be made at an increasing interval starting at 2s and doubling up to a maximum of 64s. Polling will continue at the maximum interval until a valid response has been received.

This service will provide initial time synchronisation for devices where NTP ports have been blocked. For devices where NTP access is available it should ensure that any system 'time jump' is only a few seconds when NTP synchronisation is eventually achieved. It also allows other services to start with a reasonably accurate time without having to wait for the NTP synchronisation process to complete.

Services that are ordered after the new time-sync-https-wait target can be sure that full network connectivity has been achieved and that time has been synchronised with an accuracy of a few seconds.

Change-type: minor
Connects-to: #1337 #1776 #2044 #2139
Signed-off-by: Mark Corbin mark@balena.io

--

Tested on a RPi3 under balenaOS 2.85.2+rev5 as follows:

  • Boot newly provisioned device (both with and without network cable). Check journal logs for correct time synchronisation.
  • Boot device with no saved fake-hwclock data (both with and without network cable). Check journal logs for correct time synchronisation.
  • Boot device with saved fake-hwclock data (both and without network cable). Check journal logs for correct time synchronisation.
  • Boot device with saved fake-hwclock data set in the past. Check journal logs for correct time synchronisation.
  • Boot device with saved fake-hwclock data set in the future. Check journal logs for correct time synchronisation.
  • Boot device without network cable. Check that container application starts and runs.

In all test cases the timesync-https service was observed to have set the time to within 1.5 seconds of the time subsequently obtained by chrony.


Contributor checklist

Reviewer Guidelines

  • When submitting a review, please pick:
    • 'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
    • 'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
    • 'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)

@markcorbinuk markcorbinuk added the os/time TIme synchronization overhaul label Oct 27, 2021
@resin-jenkins
Copy link

Can one of the admins verify this patch?

@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from e6d6257 to e2e8ed3 Compare October 27, 2021 16:05
Copy link
Contributor

@alexgg alexgg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good Mark

@alexgg
Copy link
Contributor

alexgg commented Nov 3, 2021

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from e2e8ed3 to 7133137 Compare November 3, 2021 11:48
@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from 7133137 to 1d7520b Compare November 5, 2021 10:09
@markcorbinuk markcorbinuk force-pushed the add-timesync-https-service branch from 1d7520b to 1536144 Compare November 5, 2021 10:53
@alexgg
Copy link
Contributor

alexgg commented Nov 5, 2021

@resin-jenkins retest this please

@alexgg
Copy link
Contributor

alexgg commented Nov 12, 2021

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from 1536144 to 20aa4a2 Compare November 12, 2021 09:23
@markcorbinuk
Copy link
Contributor Author

@resin-jenkins retest this please

1 similar comment
@markcorbinuk
Copy link
Contributor Author

@resin-jenkins retest this please

@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from 20aa4a2 to 708cdb8 Compare November 15, 2021 14:58
@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from 708cdb8 to f5d9705 Compare November 16, 2021 10:04
@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from f5d9705 to 4cbaa65 Compare November 16, 2021 16:23
@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from 4cbaa65 to 86c13e4 Compare November 17, 2021 10:04
@markcorbinuk
Copy link
Contributor Author

@resin-jenkins retest this please

2 similar comments
@markcorbinuk
Copy link
Contributor Author

@resin-jenkins retest this please

@markcorbinuk
Copy link
Contributor Author

@resin-jenkins retest this please

@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from 86c13e4 to bff4e54 Compare November 21, 2021 19:33
@alexgg
Copy link
Contributor

alexgg commented Nov 22, 2021

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from bff4e54 to 07eacef Compare November 22, 2021 12:03
@markcorbinuk
Copy link
Contributor Author

@resin-jenkins retest this please

@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from 07eacef to debd4fb Compare November 26, 2021 10:49
@markcorbinuk
Copy link
Contributor Author

@balena-ci rebase

@ghost ghost force-pushed the add-timesync-https-service branch from debd4fb to 70eb582 Compare December 1, 2021 12:39
Add a new timesync-https systemd service to synchronise the system
time at boot using an HTTPS header. The service uses curl to request
an HTTPS header from either $API_ENDPOINT/connectivity-check (default)
or the URL defined by the os.network.connectivity.uri field in
config.json. The URL used *must* return HTTP code 204 (No Content)
in response to a request so that we can determine that we have full
network connectivity and are not operating behind a captive portal.

The date field returned by a valid header is used to set the current
system time. The date/time derived from the header is assumed to be a
reasonable source of 'truth' such that it can be used to adjust the
system time both backwards and forwards. This will compensate for any
erroneous timestamps saved via fake-hwclock or any invalid data
read from an RTC.

The service will exit when a valid response has been received. Poll
attempts will be made at an increasing interval starting at 2s and
doubling up to a maximum of 64s. Polling will continue at the maximum
interval until a valid response has been received.

This service will provide initial time synchronisation for devices
where NTP ports have been blocked. For devices where NTP access is
available it should ensure that any system 'time jump' is only a few
seconds when NTP synchronisation is eventually achieved. It also
allows other services to start with a reasonably accurate time
without having to wait for the NTP synchronisation process to
complete.

Services that are ordered after the new time-sync-https-wait target
can be sure that full network connectivity has been achieved and that
time has been synchronised with an accuracy of a few seconds.

Change-type: minor
Connects-to: #1337 #1776 #2044 #2139
Signed-off-by: Mark Corbin <mark@balena.io>
@markcorbinuk markcorbinuk force-pushed the add-timesync-https-service branch from 70eb582 to 2bb1870 Compare December 1, 2021 15:03
@ghost ghost merged commit 5e247d2 into master Dec 1, 2021
@ghost ghost deleted the add-timesync-https-service branch December 1, 2021 16:23
@maggie44
Copy link

maggie44 commented Dec 2, 2021

Is there any way to tell which Balena OS version this change will feature in?

@alexgg
Copy link
Contributor

alexgg commented Dec 2, 2021

Hi @Maggie0002, it can be told either from the CHANGELOG or the git history itself - it will be included with v2.88.0.

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
os/time TIme synchronization overhaul
Projects
None yet
5 participants