cturra/docker-ntp

Question: Run NTP Offline

StefanWolf-tp opened this issue · 8 comments

Hey,

it's me again.
I have a question: Is it possible to run the server offline or more like in an (mini) intranet? I have an IPC (industrial pc) which is connected to sensor measurement systems, those systems should be synchronized in time, but neither the IPC nor the measurement systems have access to the internet or intranet they run complete autak/by there self.

Thanks for any answer

if you have an air gapped network, like you've mentioned above, then you'd need a reference clock connected to your ntp service. i've not personally run one, won't be able to provide much advice on which are best and how to go about configuring one.

here is some material on reference clocks: http://www.ntp.org/ntpfaq/NTP-s-refclk.htm

hey thanks.

i think i was not specific enought. i dont really care about that the ntp is in sync with the real world. i only want my own NTP which the time server for my devices and all other are in sync with this one.
So maybe it is possible to say your docker container that it should run in offline mode - so its not trying to sync with other NTP servers and will send out, that it has a stratum value of one. Something like that would be nice. Only that my devices are synced.

thanks for your patience with my reply! i disconnected for a short family camping vacation. 🏕️

if you're initially connected to the Internet to get time sync, chrony should continue to run and provide time services after removing that connection. however, i would expect time to skew over time, which may or may not be acceptable for your use case. this is not something i've tested, so cannot provide much advise unfortunately.

i would suggest that if you do plan on having your ntp server disconnected from the Internet for long periods of time, it makes sense to use a reference clock for your setup.

keep me posted on how you progress. i am curious to hear about your findings 😄

circling back to close this issue (question) off. still am curious to hear about your findings, so please feel free to keep me posted in here 😄

I am in the same boat. I am not able to start the container online (closed network) so is there a way to manually define the datetime for the ntp server?

this ntp container runs chronyd, which i do not believe provides the ability to manually set the clock on your time server. my understanding is the correct way of dealing with this situation is to run a reference clock (i've provided a bit of details about reference clocks in #21 (comment) above).

Hey,

sorry i don't get the time to look after this at the moment in my project but i just "found" this while searching a bit. but i cant dig any deeper at the moment.
https://chrony.tuxfamily.org/doc/3.5/chrony.conf.html

Isolated networks
This section shows how to configure chronyd for computers that never have network conectivity to any computer which ultimately derives its time from a reference clock.

In this situation, one computer is selected to be the master timeserver. The other computers are either direct clients of the master, or clients of clients.

The local directive enables a local reference mode, which allows chronyd to appear synchronised even when it is not.

The rate value in the master’s drift file needs to be set to the average rate at which the master gains or loses time. chronyd includes support for this, in the form of the manual directive and the settime command in the chronyc program.

If the master is rebooted, chronyd can re-read the drift rate from the drift file. However, the master has no accurate estimate of the current time. To get around this, the system can be configured so that the master can initially set itself to a ‘majority-vote’ of selected clients' times; this allows the clients to ‘flywheel’ the master while it is rebooting.

The smoothtime directive is useful when the clocks of the clients need to stay close together when the local time is adjusted by the settime command. The smoothing process needs to be activated by the smoothtime activate command when the local time is ready to be served. After that point, any adjustments will be smoothed out.

A typical configuration file for the master (called master) might be (assuming the clients and the master are in the 192.168.165.x subnet):

initstepslew 1 client1 client3 client6
driftfile /var/lib/chrony/drift
local stratum 8
manual
allow 192.168.165.0/24
smoothtime 400 0.01
rtcsync

For the clients that have to resynchronise the master when it restarts, the configuration file might be:

driftfile /var/lib/chrony/drift
allow 192.168.165.0/24
makestep 1.0 3
rtcsync

The rest of the clients would be the same, except that the allow directive is not required.

If there is no suitable computer to be designated as the master, or there is a requirement to keep the clients synchronised even when it fails, the orphan option of the local directive enables a special mode where the master is selected from multiple computers automatically. They all need to use the same local configuration and poll one another. The server with the smallest reference ID (which is based on its IP address) will take the role of the master and others will be synchronised to it. When it fails, the server with the second smallest reference ID will take over and so on.

A configuration file for the first server might be (assuming there are three servers called master1, master2, and master3):

server master2
server master3
driftfile /var/lib/chrony/drift
local stratum 8 orphan
manual
allow 192.168.165.0/24
rtcsync

The other servers would be the same, except the hostnames in the initstepslew and server directives would be modified to specify the other servers. Their clients might be configured to poll all three servers.

seems like that's pretty much, what we are looking for.

Can someone explain the oddly protective subculture that surrounds ntp, that I had no idea existed, until faced with the same requirement as the OP; a couple hours ago, I expected maybe a five minute jaunt through docker hub, which has since transformed into disbelief that there isn't a stupid simple means of syncing time across multiple devices in a lan. Not only is there not a simple solution, there isn't really any straight forward solution and queries like this are met with something like outrage from purists, who I assume are assuming that the intent is driven by something nefarious and stupid.

Which is perfect, and obviously I am biased, because that is exactly what my intent is: as an american, who spends part of the year in the eu, it's become increasingly more important to present as in-country, unless you enjoy elevated security challenges, every day, multiple times a day. I recently found out that If you present a valid US residential ip, and appopriate tz on your dev box, which is signed into a popular provider, which is also signed into an iot device with a danish ip, well enjoy veriying across all of your associated accounts. Route everything through your American IP, but god forbid, forget to change tz on any device that has a browser, which can perform a UTC check, and congrats, your bank account is locked until you can speak with an associate, who will not be available for 12 hours.

Sorry, I am in a ranty mood; anyways, as part of a depth in defense approach I need a method of syncing time across all devices, with little concern about drift; at least until i forget and spend days trying to figure out why any eventually consistent cluster/store is broken in my local. Perhaps I am leaning stupid here, which is usually the case when something obvious doesn't exist, but I would be shocked if that were the case. Of course I am shocked everytime, so.. anyways, thank you @StefanWolf-tp for proving something exists, though not the one liner I was expecting.

Cheers