Score:0

Synching time and date of two Ubuntu machines not connected to the internet

br flag

I have two machines

  1. machine A with ip 192.168.0.2
  2. machine B with assigned IP 192.168.0.3

They are both connected to a local network and I would like to set the date and time of machine A to match those of machine B.

For a similar problem I would use the solution provided in this answer.

sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

However, this would only work if I had an internet connection.

What is the command to sync the time and date of two Ubuntu operating systems without using the internet?

Candidate 1 Thanks to @Joe for the his input. What about setting up a webserver on machine B, querying it from machine A and get the time and date from the response? It looks quite articulated.. is there an easier solution?

Candidate 2 Thanks to @matigo for this. Setting up an NTP server on the local network. Checking NTP docs to implement this solution

in flag
Is it possible for “machine A” to have some software installed? Setting up an NTP server on the local network seems the most logical solution
UserK avatar
br flag
Yes, I am free to modify both systems pre-deployment. But the solution should be then automated and deployed in an isolated network
raj avatar
cn flag
raj
This is definitely an overkill, but I just want to note that it is possible to buy a hardware NTP server that gets the reference time from GPS signal, connect it to a local network and have both machines sync to it. These devices are quite expensive, but I have seen this solution used in isolated networks to synchronize to actual clock time.
cn flag
"local network" Is there a router in there? if so what OS does it have?
UserK avatar
br flag
Thank @raj for your army-ready solution! But this would require a GPS receiver for each machine, then a script to parse the NMEA message over serial, get the timestamp of satellites and set it locally. Yes as you said, it's an overkill.
UserK avatar
br flag
@Rinzwind Yes there is. There is a third machine that is actually a router running Ubuntu 22.04. I just simplified the scenario to create this question
cn flag
Well it is possible to probe the router for its time and have both systems sync on that. Probably easier, And you could have the time resync on connect to the network.
UserK avatar
br flag
Sounds great! Could you elaborate on "probe the router for its time". Thanks
UserK avatar
br flag
I asked gpt4 to rephrase my comment to make it sound more polite. Sorry @Rinzwing I am not an English native speaker. "Thank you for your suggestion to 'probe the router for its time.' I'm not quite familiar with this concept. Could you please provide more details or clarify the process? I appreciate your help!"
raj avatar
cn flag
raj
@UserK no GPS receiver for each machine required. The time server is a ready to use device that has a built in GPS receiver and is connected to the network. In the network it is visible as a normal NTP server, you synchronize machines to it over the network using NTP. You only need one device in the network.
raj avatar
cn flag
raj
@UserK This is an example of such device: https://timemachinescorp.com/product/gps-time-server-tm1000a/
Score:2
uz flag
Jos

If had an internet connection, you could enter the wget command given inside the date command, and see that it yields a time string like this:

25 Apr 2023 13:20:23Z

It does so by taking the date from a HTTP header, stripping off the word "Date:", and tacking a Z at the end. So you can set the time manually by using this format:

sudo date -s "25 Apr 2023 13:20:23Z" 

You may possible need to translate "Apr" to an abbreviated month name in your locale.

UserK avatar
br flag
Thanks for your answer Jos, Ok I think I am getting closer. What about setting up a simple webserver on machine B that answers back with the date and time. It could then be queried by machine A. Maybe it is too complicated and there is an easier or built in solution. Please note that the solution should be automatically executed by one of the two machines as soon as it boots up.
UserK avatar
br flag
Well, not even needed, I could at that point just use the time and date of the HTTP response and use it to set the one of machine A.. waiting for other inputs from the community
Score:1
cn flag
raj

Setting up a NTP server (as far as I know current Ubuntu versions use chronyd as NTP server) on one machine and using a NTP client (chronyc, conversely) on the other to sync to the server machine seems to be the best way.

Another option is to use the "good old" Daytime Protocol. You need to install xinetd on the server machine (the one you will be synchronizing to) and enable daytime service in its configuration (here is some info on how to enable it). Daytime service returns current date and time as a string, so you probably have to write some script on the client machine (the one you want to synchronize to the client machine) to retrieve this information and set clock according to it (I don't know of any ready-made client for daytime protocol). But using NTP still seems better...

UserK avatar
br flag
Thanks for your double input @raj. Let me investigate your solution
Score:0
tg flag

I'm assuming 192.168.0.* must remain inaccessible to and from anywhere else, on account of some security concern. To get external time without too much effort, how about:

  1. install an hypervisor on a different machine with internet access. (It would be ideal if this machine had 2 Ethernet connections, 1 of which facing the internet, the other unused or used for local-only networks)
  2. make this machine a time client of some time server (NTP, Windows domain, whatever).
  3. install a guest OS which is a pre-built NTP server appliance
  4. give the guest appliance a bridged address within 192.168.0.*
  5. Sync this guest time to the host time by means of the hypervisor.
  6. Make this guest itself the self-contained root source for NTP time.
  7. Make all machines on 192.168.0.* NTP clients to this guest appliance

Because the hypervisor (and not a network route) internal mechanism is the means to pass a time reference to the NTP guest appliance, 192.168.0.* has no route to the outside, but still has a good time reference. If the hypervisor host has a network cable used only for local networks, even a promiscuous-mode tap on the outside wire would share nothing of 192.168.0.*

Score:0
br flag

All right, thanks for the precious info you guys provided. After a bit of research and testing here is the solution that I am using.

As Canonical stated here

Since Ubuntu 16.04, timedatectl/timesyncd (which are part of systemd) replace most of ntpdate/ntp.

[...]

ntpdate is now considered deprecated in favor of timedatectl (or chrony) and is no longer installed by default. timesyncd will generally do the right thing keeping your time in sync, and chrony will help with more complex cases.

So I gave Chrony a shot. I also checked:

  1. this link here
  2. Stack question,
  3. The Red Hat page
  4. This tutorial

So long story short...

Machine A - Configured as NTP server

sudo apt update && sudo apt upgrade
sudo apt install chrony
sudo vim /etc/chrony/chrony.conf

Configure the NTP server make sure to add local stratum 10 and allow 192.168.0.0/24 to force the server to work normally even if it is disconnected from the internet and that clients on this network are allowed to connect to our Chrony NTP server for time syncing.

confdir /etc/chrony/conf.d
pool ntp.ubuntu.com        iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2
allow 192.168.0.0/24
sourcedir /run/chrony-dhcp
sourcedir /etc/chrony/sources.d
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
ntsdumpdir /var/lib/chrony
logdir /var/log/chrony
maxupdateskew 100.0
rtcsync
makestep 1 3
leapsectz right/UTC

Restart the chrony service, check that is running and enable it to start on boot

sudo systemctl restart chrony
sudo systemctl status chrony
CTRL+C
sudo systemctl enable chrony

Machine B - Configured as Chrony Client

Synch the date and time with a pool of servers and set the 192.168.0.1 or whichever IP you have as the preferred server.

sudo apt update && sudo apt upgrade
sudo apt install chrony
sudo vim /etc/chrony/chrony.conf

Add your local NTP server to the pool.

pool 192.168.0.1 iburst prefer
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
log measurements statistics tracking
maxupdateskew 100.0
rtcsync
makestep 1.0 3

Restart, check the service and enable it at startup

sudo systemctl restart chrony
sudo systemctl status chrony
CTRL+C
sudo systemctl enable chrony

Finally, check if it gets the update from the right source

chronyc tracking
chronyc sources

Conclusion

Rock n' roll and keep pushing!

I will be conducting a brief test and will update this post with any issues I come across.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.