Hey Richard. On Tue, 2022-01-18 at 20:33 -0600, Richard Laager wrote: > 1. What is your use case for ntpdig and/or ntpdate (please be > specific > which) if not for the hooks? Well it's mostly what I've semi-indicated already:
- I wouldn't want all the hooks, as for normal operations I have ntpsec running. - But *if* for some reason the system time deviated to far from the real time (e.g. when it was changed manually for some debugging or so, or when the system was longer powered of and the clock is bad),... where the daemon would take to long to correct,... it would be nice to have a manual(!) one-shot command which simply sets the time to what every is determined via NTP (well ideally NTS, but ntpdig doesn't seem to support that). An alternative would of course be to use -g and/or -G ... but that I wouldn't want to set in general. > 2. My recollection is that there was some talk about removing ntpdate > from Debian's src:ntp. I don't know if that's already happened. > > I ended up implementing all that in Debian's src:ntpsec for > compatibility with ntp, but I intended on removing it once ntp did. I thought the plan was to replace ntpdate with sntp? > The network hooks do a couple of different things. First, if you're > using ifupdown, then when an interface comes up, ntpsec is stopped, > ntpdate is run, and ntpsec is started. This is arguably* desirable if > the system is not always connected to the Internet. If it then fetches the current time every time... and if ntpdig doesn't use NTS... doesn't that give an attacker the chance to mess with the time rather easily? > * But why not either: A) run systemd-timesyncd (the default anyway) I think that has (not yet) support for NTS? > 3. The DHCP bit can be turned off in /etc/default/ntpsec-ntpdate. > Disabling running ntpdate on ifup would require deleting the hook > script. Well that's why I kinda wanted not to have the hooks at all, but just the tool,... so that I don't need to worry how far or not they integrated into NM/ifupdown/etc.. Cheers, Chris.
