System Time

There’s no excuse for a system having incorrect time. Once you set the time zone, having OpenBSD correct its own clock on an ongoing basis from any number of freely available network time servers is easy. Virtual machines in particular are notorious for skewing clocks, but time correction works on them as well, so as I said, no excuse.

OpenBSD includes its own NTP client, OpenNTPD, which is written to be safe and secure. Before ntpd(8) can do anything though, it needs some configuration.

Configuring ntpd(8)

OpenBSD comes with a perfectly acceptable generic ntpd configuration that uses public time servers. If your host is on the public Internet and you only want to set your system time, not provide time to other hosts, use the defaults. Otherwise, you must customize /etc/ntpd.conf by selecting time sources and deciding if ntpd will accept time requests from other machines.

Time Redundancy

NTP gets the time by querying remote servers. If you have a single server, that time is assumed to be correct. However, if you have multiple time servers, the times are not simply averaged. If one time server is wildly off from all of the other time servers, the results from that server are discarded, and a median from the remainder is selected. If you have only two time servers, and the times obtained from them differ, ntpd can’t determine which one is correct. To help ntpd make sensible decisions, always list at least three time servers.

Time Sources

Choose your time sources with the server, servers, and sensor keywords.

The server option tells ntpd to get the time from a single server, which might have multiple IP addresses. If that’s the case, ntpd tries to use the first IP address. If the first address doesn’t work, it tries the second, and so on, until it gets an answer. Use the server option if you have specific time servers to use, and be sure to list at least three time servers.

server time1.blackhelicopters.org
server time2.blackhelicopters.org
server time3.blackhelicopters.org

The servers option tells ntpd to get the time from multiple hosts that share a common hostname. The default ntpd.conf includes this entry:

servers pool.ntp.org

The host pool.ntp.org has four IP addresses, and ntpd will try to get time from all of those hosts.

If you have a hardware time sensor, you can tell ntpd to read time from it. Hardware time sensors include nmea(4), udcf(4), and mbg(4). The sensor option tells ntpd to use a hardware sensor. If you’ve invested in a hardware time sensor, you might be sufficiently concerned about time to measure the distance between the transmitter and the receiver, and adjust the time based on the speed of light delay. The correction keyword lets you specify a number of microseconds that your sensor is behind.

As I wrote this, a 40-millisecond (ms) delay caused a furor in the scientific world when researchers thought they might have seen a neutrino go faster than light, so we’ll put a 40 ms correction into our time sensor.

sensor nmea0 correction 40000

Note

Be warned that OpenBSD is not a real-time operating system. You should not be measuring neutrino speed with it anyway!

Serving Time

I run time servers on only closed networks, where very few hosts have access to the public Internet. I would also run time servers if I had hardware time sensors, but most of the time, I just use the public time servers.

To have ntpd answer time queries from other hosts, use the listen on directive. You can either specify an IP address or use an asterisk to say “every IP on the system.”

listen on 192.0.2.87
listen on 2001:db8::aaaa

Because ntpd has no access controls, any host that can connect to port 123/UDP can get time from this server. If this worries you, use packet filtering (discussed in Chapter 21 and Chapter 22) to limit time checks to hosts on your network. The author of OpenNTP served time to his entire company and to the public on a MicroVAX 3100 with 16MB (yes, that’s an M) of RAM without the NTP process using more than 5 percent of the processor, so the load imposed by NTP is negligible on modern systems.

Now that ntpd is configured, let’s use it.

Using ntpd(8)

You can correct time slowly or do it in one fell swoop. I recommend fully correcting time at boot, and then letting ntpd slowly adjust the system clock as the system runs. This corrects time before anything relies on it, but keeps everything synchronized on an ongoing basis.

To correct time when starting ntpd, use the -s flag.

# ntpd -s

You’ll get a command prompt back once ntpd receives a response from a time server and adjusts the clock. At boot, this delays other software starting so that it has the correct time, and when you check your clock, you should see the correct time. You can configure this at boot with ntpd_flags in /etc/rc.conf.local.

ntpd_flags='-s'

If the clock is off on a running system and you’re running software that would be corrupted by the clock moving backward or a time jump forward (as with many databases), you might need to tell ntpd to correct the clock more slowly. To do so, run ntpd without any flags, or set it in rc.conf.local to have it run in this mode at boot.

Note

Your starting time may be so far off that it will be impossible to make a gradual adjustment to the correct time in any reasonable period. To fix the clock, schedule a clock change when you can shut down your sensitive software, and make sure NTP runs afterwards so that the problem remains fixed. It’s better to fix your clock right away and be done with it.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.22.71.106