9 ms·

If Ntimed separates out the client from the daemon, so I can install just the client package only, IMO that will be a big win for computer time synchronization.

If Ntimed separates out the client from the daemon, so I can install just the client package only, IMO that will be a big win for computer time synchronization. One thing that has always bothered me with the NTP project, is the lack of a separate daemon and client. If you want the NTP project's client, then you must also install the daemon, even if it is listening only on localhost, or if you opt to not start it up on boot. It still must be installed though. On my Debian system, I only have the following "clients" available: * libnet-ntp-perl * openntpd (which also installs a listening daemon) * python-ntplib In most cases, such as on my laptop, workstations, and embedded systems, I don't want the complexities of a full blown daemon running, nor do I want to manage firewalling and configuring the daemon to listen on localhost to prevent remote queries. The only other two options are programming libraries. As such, I'm looking forward to systemd-timesyncd. It implements a simple SNTP client to synchronize your clock. As such, the full NTP complexity is not a concern. This is very likely an attractive scenario for most GNU/Linux installations, as most users won't be interested in running an NTP daemon synchronizing other NTP client clocks.

swinglock 12y ago
Debian has a chrony package as well, another alternative ntpd.
- easytiger 12y ago
  That simply won't do for OP as he seems to want solely client only mode implementation of NTP. chrony supports both. He seems to think the authors of these daemons don't have his best interests at heart by adding functionality he doesn't want personally yet many other people will use.
  - phkamp 12y ago
    I fully agree with him that client-only mode deserves its own program, given that less than 1% of all computers ever need to be NTP servers.
    - digi_owl 12y ago
      And yet he wants to go systemd...
    - rab_oof 12y ago
      OSX uses sntp which is open source, but it sucks because it doesn't stay running so it doesn't establish a PLL feedback loop that ntimed and ntp do. Q: Does openntpd hook into PLL infrastructure?
    - easytiger 12y ago
      How is that different than running the existing code in client only mode? That configured operation is just as easy to test and verify.
easytiger 12y ago
> One thing that has always bothered me with the NTP project, is the lack of a separate daemon and client. > In most cases, such as on my laptop, workstations, and embedded systems, I don't want the complexities of a full blown daemon running Pretty confused. Why would you care about a code path that isn't executed? Are upset about losing a few kb of disk space? What is the alternative to "a full blown daemon". Can you demonstrate how that is an issue for anyone? Your comment also shows a fundamental misunderstanding of NTP. It's a peer-to-peer protocol in many use cases, as is PTP so instances have to run as client & server.
- Ricapar 12y ago
  It's just good security practice. Even if the code path is never intended to be executed, there are bugs in code that could lead to it. Yes, it's a P2P protocol, but when you're managing a bunch of servers, you don't use it as such. You set up one server in your environment (time.example.com) and have all your boxes sync to that. Why would appserv.example.com EVER need to be able to accept NTP connections from anyone else?
  - mkhpalm 12y ago
    You are looking for ntpdate executed regularly from a scheduled task. Its a sawtooth drift/snap pattern but it seems to be good enough for MS. That said, a slightly configured ntp doesn't ever accept ntp connections from anyone else. Thats not like a requirement or anything.
  - easytiger 12y ago
    Run it in client only mode and it won't
- atoponce 12y ago
  Well, in the case of SSDs, every byte counts. But no, that's not my concern. My concern is installing a binary I have no intention of using. It's solid security best practices to only install what you need, and leave the rest out. Also, I don't have a "fundamental misunderstanding of NTP". I've blogged about it quite a bit: https://pthree.org/2013/11/05/real-life-ntp/ https://pthree.org/2013/11/05/real-life-ntp/ https://pthree.org/2013/10/13/ntp-drift-file/ https://pthree.org/2013/10/13/ntp-drift-file/ https://pthree.org/2013/10/12/new-public-ntp-server/ https://pthree.org/2013/10/12/new-public-ntp-server/ http://transmission.xmission.com/2014/05/28/building-a-stratum-1-ntp-server-with-a-raspberry-pi http://transmission.xmission.com/2014/05/28/building-a-strat...
deleted 12y ago
[deleted]

swinglock 12y ago

Debian has a chrony package as well, another alternative ntpd.

easytiger 12y ago
That simply won't do for OP as he seems to want solely client only mode implementation of NTP. chrony supports both. He seems to think the authors of these daemons don't have his best interests at heart by adding functionality he doesn't want personally yet many other people will use.
- phkamp 12y ago
  I fully agree with him that client-only mode deserves its own program, given that less than 1% of all computers ever need to be NTP servers.
  - digi_owl 12y ago
    And yet he wants to go systemd...
  - rab_oof 12y ago
    OSX uses sntp which is open source, but it sucks because it doesn't stay running so it doesn't establish a PLL feedback loop that ntimed and ntp do. Q: Does openntpd hook into PLL infrastructure?
  - easytiger 12y ago
    How is that different than running the existing code in client only mode? That configured operation is just as easy to test and verify.

easytiger 12y ago

> One thing that has always bothered me with the NTP project, is the lack of a separate daemon and client. > In most cases, such as on my laptop, workstations, and embedded systems, I don't want the complexities of a full blown daemon running Pretty confused. Why would you care about a code path that isn't executed? Are upset about losing a few kb of disk space? What is the alternative to "a full blown daemon". Can you demonstrate how that is an issue for anyone? Your comment also shows a fundamental misunderstanding of NTP. It's a peer-to-peer protocol in many use cases, as is PTP so instances have to run as client & server.

Ricapar 12y ago
It's just good security practice. Even if the code path is never intended to be executed, there are bugs in code that could lead to it. Yes, it's a P2P protocol, but when you're managing a bunch of servers, you don't use it as such. You set up one server in your environment (time.example.com) and have all your boxes sync to that. Why would appserv.example.com EVER need to be able to accept NTP connections from anyone else?
- mkhpalm 12y ago
  You are looking for ntpdate executed regularly from a scheduled task. Its a sawtooth drift/snap pattern but it seems to be good enough for MS. That said, a slightly configured ntp doesn't ever accept ntp connections from anyone else. Thats not like a requirement or anything.
- easytiger 12y ago
  Run it in client only mode and it won't
atoponce 12y ago
Well, in the case of SSDs, every byte counts. But no, that's not my concern. My concern is installing a binary I have no intention of using. It's solid security best practices to only install what you need, and leave the rest out. Also, I don't have a "fundamental misunderstanding of NTP". I've blogged about it quite a bit: https://pthree.org/2013/11/05/real-life-ntp/ https://pthree.org/2013/11/05/real-life-ntp/ https://pthree.org/2013/10/13/ntp-drift-file/ https://pthree.org/2013/10/13/ntp-drift-file/ https://pthree.org/2013/10/12/new-public-ntp-server/ https://pthree.org/2013/10/12/new-public-ntp-server/ http://transmission.xmission.com/2014/05/28/building-a-stratum-1-ntp-server-with-a-raspberry-pi http://transmission.xmission.com/2014/05/28/building-a-strat...

deleted 12y ago

[deleted]