4 ms·

> 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,

> 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...
- easytiger 12y ago
  > It's solid security best practices to only install what you need, and leave the rest out. You are installing only what you need. And running it in the mode you suggested, client only, will lead to no philosophically different a state than a all new client that does the same thing. Once you set it running as a privileged user it cannot be modified by other users. It will have been tested in your environment and signed off by your infosec team if that isn't you. How is that different from any other piece of software that has options you should never use? Are you saying if your users use git that the 'bisect' command should be removed because they never need to use it?
feld 12y ago
Have you met BIND?

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...

easytiger 12y ago
> It's solid security best practices to only install what you need, and leave the rest out. You are installing only what you need. And running it in the mode you suggested, client only, will lead to no philosophically different a state than a all new client that does the same thing. Once you set it running as a privileged user it cannot be modified by other users. It will have been tested in your environment and signed off by your infosec team if that isn't you. How is that different from any other piece of software that has options you should never use? Are you saying if your users use git that the 'bisect' command should be removed because they never need to use it?

feld 12y ago

Have you met BIND?