Easy Time Sync

[BrandyWine]

Instead of using the ntpd in client mode, it's just easy to create an actions conf for ntpdate, then cron it 4x daily.

After you create the action do "service configd restart", then it shows up in cron area of gui. In cron you enter "-s [ntp dns name]" for parameter.

My /usr/local/opnsense/service/conf/actions.d/actions_timeupdate.conf

[sync]
command:/usr/local/sbin/ntpdate
parameters:%s
type:script
message:Syncing time with %s
description:Update local time

[bimbar]

Sure, but why?

[meyergru]

Very bad idea. A continuous update is way better than sudden jumps. See this for a striking example of why you should never use periodic ntpdate.

[BrandyWine]

I address both.

Why? because no need to run a daemon that needs way more resources.
Issues? Not sure, I have used ntpdate in cron for many years across various nix OS's in various environments. I never did experience an issue.

[Patrick M. Hausen]

If you do that the time might go backwards. This must never happen by definition on a Unix system. The running daemon adjusts the clock in a way that time only moves forward. That's the reason why ntpd exists. Resources well spent.

[meyergru]

Well spoken, Patrick.

@Brandywine: You may not have, yet, but I actually did - and it was exactly the Dovecot issue that I linked to. It took me days to find why I got no more E-Mails. Backward jumps are the more common case with ntpdate, since most computer clocks are too fast, because nobody ever spents the money on a variable ballast capacitor on those clock crystals.

When you look for "backward time jump problem", you will find dozens of examples of services that do not "like" this, including Asterisk and dozens of others.

[BrandyWine]

Maybe an misunderstanding of ntpdate?
It can step, it can also slew, we like the latter.

ntpdate slews local clock when diff in less than 0.5sec.
If the local system has 0.5sec drift within 6hr period, then something is wrong with the system hardware.

If the local clock is that bad (.5s in 6hr), you can avoid stepping the clock by running ntpdate every 1-2 hour.

It not an issue with using ntpdate, it's an issue on how it is used on systems that have very bad clock drifts.

That Dovecot page didnt explain how ntpdate was being used that it had to step -2s. Sounds like 1) bad local clock, or 2) running ntpdate was not frequent enough.

[Greg_E]

I get why you might want to run a cron to do this, but is it really saving you anything? Even on my lowest power computers I'm not seeing spikes in CPU when it checks ntp servers. Maybe I don't load them enough to see the issue. I also don't see any advantage on my OPNsense, I keep it synced to my GNSS locked NTP server appliance.

The only benefit I can see is if there was an attack on time servers, spoofing a date far forward or far backward could cause real problems with licensing, file shares, secure email and secure web which all depend on "close enough" time sync.

I have seen some really bad internal clocks too, I had one old server that would lose a couple minutes in a day. This is the server that caused me to buy my first GPS NTP server. It also happened to be my Windows AD server which caused all sorts of issues on the domain. It was a good lower end Supermicro x7 series which makes this surprising.

[meyergru]

I know that ntpdate does adjtime() when the difference is small. However, you did not say that you should run it every 1-2 hours initially, but "4x  daily".

As for the accuracy of standard PC clocks, see this: https://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality/#AEN1230

I personally saw computer clocks having a drift of 50 PPM, which correspond to 4 seconds per day, with 20-30 PPM being a valid assumption for most clocks. You will find many reports of clock skews of > 10s per day.

Adding to this, ntpdate by design is unable to account for network latency and jitter, unlike ntpd or chrony. I also never saw any relevant load by those daemons.
ntpdate is the means of choice for a one-shot correction on system startup in case the CMOS battery is dead or the internal clock is off for other reasons - and most Linux distributions used it like that before systemd took over that task.

@Greg_E: The "attack" scenario can be ruled out more easily with a daemon, because it takes its time from a set of servers, which makes it more robust than a single call against a specific time server like ntpdate does it. There is also an election login that eliminates outliers build into ntp. This has led to confusion because initially after start, no server is trusted until that logic has settled.

[BrandyWine]

I would normally have an internal ntpd that is my local authoritative time source, then all other devices/hosts would use that for time. I don't run a local ntpd server/appliance/device.

The concerns and issues listed are not to be discounted, but for my OPNsense fw using ntpdate 4x daily works good. If running it 24x daily is not enough to keep it in slew adjust, then perhaps use something else.

As for resources, on a small N100/150 device where resources are very limited, saving on resources is the game (give all resources to OPNsense stuff). We're not gonna see cpu or mem spikes when ntpd does a ntp sync, it's too small to recognize within the other hog processes that are running. An idle daemon still needs mem and kernel time to track it's state and manage it, etc. Don't need any of that by invoking a utility that runs and exits.

[Patrick M. Hausen]

Different philosophy, it seems. I run ntpd on every system and point these to my local stratum 1 source. I also run snmpd on everything considered a server or "infrastructure". And lldpd. And collectd sending to my central influxdb. Etc.

[Kets_One]

A little off-topic, but i have observed quite some difference between the behavior of the chrony plugin vs. the standard "Network Time".
Network time ppears to make regular 'jumps' and shows some erratic behavior, whereas chrony does not.
Don't if you are familiar with the NTP Pool, but this is a graph of one of my servers participating in the pool.
Whows the measured offset over time. Every green dot is a measurement of offset. Some monitors are further away than others, so distance plays a role in the measurement results, but overall the dots are nicely grouped around the center line (0ms offset).

I'll try to post an example of NTPd also.

[BrandyWine]

When you say "Network time ppears to make regular 'jumps' and shows some erratic behavior, whereas chrony does not.", are you referring to ntpd client mode from OPNsense gui vs using the chrony plugin solution?

And then, you mention pool.ntp.org, are you suggesting that source is better than others?

[Kets_One]

@brandywine
Yes indeed i am referring to ntpd client mode from Opnsense GUI vs. chrony plugin.

[BrandyWine]

Different philosophy, it seems. I run ntpd on every system and point these to my local stratum 1 source. I also run snmpd on everything considered a server or "infrastructure". And lldpd. And collectd sending to my central influxdb. Etc.

ntpd with udp and possibly tcp 123 listeners? Or do you mean configured to run "ntpd -q" ?