4 ms·

If you're looking for a simple security-oriented ntpd, I can't recommend OpenNTPd enough. It's cross platform and available for most Linux distros in packages.

If you're looking for a simple security-oriented ntpd, I can't recommend OpenNTPd enough. It's cross platform and available for most Linux distros in packages. http://www.openntpd.org http://www.openntpd.org I have a much higher trust level for OpenBSD on security issues than I do with either of these projects.

ars 10y ago
Just remember not to use OpenBSD or OpenNTP for time servers, they can only be used as clients. (This is because neither supports leap seconds, so using them as servers will cause clients to desynchronize. Their belief that we don't need leap seconds is quite irrelevant: Right now we have them.)
- iso-8859-1 10y ago
  What do you mean when you say "we have them"? Because they are in UTC? RFC5905 (NTP 4) notes: The goal of the NTP algorithms is to minimize both the time difference and frequency difference between UTC and the system clock. When these differences have been reduced below nominal tolerances, the system clock is said to be synchronized to UTC. Since nominal tolerances are not defined in the standard, a server would still be NTP conforming if it smeared the leap second.
  - ars 10y ago
    > What do you mean when you say "we have them"? Because they are in UTC? They are part of the time standard used by the entire world. BSD doesn't like them, fine, but pretending (in their code) that they don't exist is not the correct approach. It works more or less fine for clients, but not for servers. > a server would still be NTP conforming if it smeared the leap second Not really. Consider the situation if a client is speaking to multiple servers, some normal servers, some buggy BSD servers. Consider a client that manages to do a mixture of correctly applying a leap second, while also doing time smearing because an upstream source is doing time smearing. BSD is simply doing the wrong thing here. (My understanding is that BSD time servers are not permitted in the ntp pool because of the problems they cause.)
    - floatboth 10y ago
      Of course you shouldn't mix servers that handle and ignore the leap second in one pool, so OpenNTPD servers aren't accepted in the ntp.org pool. Doesn't mean you can't run OpenNTPD as an internal server for your machines :) http://marc.info/?l=openbsd-misc&m=143544318718489&w=2 http://marc.info/?l=openbsd-misc&m=143544318718489&w=2
mjw1007 10y ago
I tried using OpenNTPd as the ntp client on a slow virtual server last year. It seemed like perfectly decent software except for the fact that it failed to keep the time in sync. I switched to the usual (ntp.org) ntpd, with the same pool servers, and it worked fine.
- iso-8859-1 10y ago
  Did you try to diagnose the problem or did you just switch? I can't take such a vague bug report seriously.
  - mjw1007 10y ago
    I didn't try to diagnose the problem. I just switched. I do not claim that OpenNTPD has a bug. Maybe it has requirements on the quality of the local clock that the virtual machine didn't meet. Maybe it has requirements on the remote time sources or the network that the setup didn't meet. What I do know is that over the years I've deployed ntp-over-the-Internet in a dozen or two different setups (including some user-mode-Linux ones with really poor local clocks), and ntp.org's ntpd has always managed to sync the clock. The one time I gave OpenNTPD a go it didn't. Looking at the log, I was running it for several months. After a while I got tired of fixing it manually when the clock was a few seconds out.

ars 10y ago

Just remember not to use OpenBSD or OpenNTP for time servers, they can only be used as clients. (This is because neither supports leap seconds, so using them as servers will cause clients to desynchronize. Their belief that we don't need leap seconds is quite irrelevant: Right now we have them.)

iso-8859-1 10y ago
What do you mean when you say "we have them"? Because they are in UTC? RFC5905 (NTP 4) notes: The goal of the NTP algorithms is to minimize both the time difference and frequency difference between UTC and the system clock. When these differences have been reduced below nominal tolerances, the system clock is said to be synchronized to UTC. Since nominal tolerances are not defined in the standard, a server would still be NTP conforming if it smeared the leap second.
- ars 10y ago
  > What do you mean when you say "we have them"? Because they are in UTC? They are part of the time standard used by the entire world. BSD doesn't like them, fine, but pretending (in their code) that they don't exist is not the correct approach. It works more or less fine for clients, but not for servers. > a server would still be NTP conforming if it smeared the leap second Not really. Consider the situation if a client is speaking to multiple servers, some normal servers, some buggy BSD servers. Consider a client that manages to do a mixture of correctly applying a leap second, while also doing time smearing because an upstream source is doing time smearing. BSD is simply doing the wrong thing here. (My understanding is that BSD time servers are not permitted in the ntp pool because of the problems they cause.)
  - floatboth 10y ago
    Of course you shouldn't mix servers that handle and ignore the leap second in one pool, so OpenNTPD servers aren't accepted in the ntp.org pool. Doesn't mean you can't run OpenNTPD as an internal server for your machines :) http://marc.info/?l=openbsd-misc&m=143544318718489&w=2 http://marc.info/?l=openbsd-misc&m=143544318718489&w=2

mjw1007 10y ago

I tried using OpenNTPd as the ntp client on a slow virtual server last year. It seemed like perfectly decent software except for the fact that it failed to keep the time in sync. I switched to the usual (ntp.org) ntpd, with the same pool servers, and it worked fine.

iso-8859-1 10y ago
Did you try to diagnose the problem or did you just switch? I can't take such a vague bug report seriously.
- mjw1007 10y ago
  I didn't try to diagnose the problem. I just switched. I do not claim that OpenNTPD has a bug. Maybe it has requirements on the quality of the local clock that the virtual machine didn't meet. Maybe it has requirements on the remote time sources or the network that the setup didn't meet. What I do know is that over the years I've deployed ntp-over-the-Internet in a dozen or two different setups (including some user-mode-Linux ones with really poor local clocks), and ntp.org's ntpd has always managed to sync the clock. The one time I gave OpenNTPD a go it didn't. Looking at the log, I was running it for several months. After a while I got tired of fixing it manually when the clock was a few seconds out.