There are times when your DeepSurface console server clock time may be out of sync with the rest of the world. It's important to keep this clock in sync for a variety of reasons, especially for cryptographic protocols that require time to be correct within a very short window (within seconds or even milliseconds).
The DeepSurface console is shipped with two mechanisms for keeping the system clock up to date: openntpd
and ntpdate
. ntpdate
can be used to set the correct time immediately, and openntpd
can be used to keep the clock in sync as time passes.
Virtual Machine Hibernation
If the DeepSurface console is in a virtual machine that has been paused/suspended and then had its operation continued at a later time without syncing its clock upon waking, this command can be used to immediately update the internal clock (note that this command also pauses and restarts openntpd
because ntpdate
may not be able to change the system clock time while openntpd
is running):
sudo systemctl stop openntpd
sudo ntpdate pool.ntp.org
sudo systemctl start openntpd
To keep this problem from happening again, your virtual machine platform may have documentation for keeping the guest clock in sync with the host clock.
openntpd
Can't Communicate With NTP Servers
In order to sync the clock, openntpd
needs to be able to reach at least one clock sync server. The ntp
protocol works using UDP over port 123
. By default, openntpd
is configured with a few specific domain names of NTP server pools, such as 0.debian.pool.ntp.org
and 1.debian.pool.ntp.org
.
These two commands can be used to debug and verify that openntpd
can talk to upstream servers:
ntpctl -s status
ntpctl -s all
Note that the DNS records for public NTP servers often point to large numbers of IP addresses that change over time. If your firewall is configured to open NTP access to the IP addresses of NTP servers, there is a risk these servers will become inaccessible later when the public servers change.
Your organization may have a clock sync server or be able to turn a Domain Controller into a time controller, in which case the openntpd
configuration can be updated to sync with that server. In this case, the /etc/openntpd/ntpd.conf
file can be updated to have lines like these pointing to your clock servers:
servers clock.yourcompany.com
servers clock2.yourcompany.com
servers 192.168.8.17
servers 192.168.5.3
If you do not have access to an organizational clock sync server, you may want to select a few specific IP addresses of trustworthy NTP servers to link your openntpd
configuration to. You may refer to ntp.org's documentation page on NTP Pool Servers on guidance of how to choose and obtain permission to use a public NTP server that will work for you.
Sometimes, the sudo ntpdate pool.ntp.org
command may work even when openntpd
fails. In this case, it may be possible to set up a cron job that will allow the DeepSurface console server to sync at regular intervals. Because this will not fix clock skew and clock drift, it may not be sufficient to keep your clock within reasonable bounds from one time the cron job runs to the next. Because of this, it is strongly urged that openntpd
is set up and allowed to communicate with an NTP server rather than using this method.
To edit the cron job, ssh
into your DeepSurface console server, and use sudo crontab -e
to pull up the cron file. Then, add this line:
## every 2 hours on the 5-minute mark, sync the clock
5 */2 * * * /sbin/ntpdate pool.ntp.org &>/dev/null
The time period may need to be adjusted to keep the clock within an acceptable range. For example, if the clock should be synced every hour, then */2
would become *
.
NTP's support wiki can be found at https://support.ntp.org.
The following manpages can be reference for further details:
man openntpd
man ntpd.conf
man ntpdate