Richard Laager via devel :
> The Debian man page for ntpdate has this BUGS section:
> The slew adjustment is actually 50% larger than the measured offset,
> since this (it is argued) will tend to keep a badly drifting clock more
> accurate. This is probably not a good idea and may cause a
The Debian man page for ntpdate has this BUGS section:
The slew adjustment is actually 50% larger than the measured offset,
since this (it is argued) will tend to keep a badly drifting clock more
accurate. This is probably not a good idea and may cause a troubling
hunt for some values of
> I just realised something: LetsEncrypt certs are max 90 days. When I renew
> them, will I need to restart NTPd?
Interesting timing. Richard's recent message reminded be of that issue.
Currently, you have to restart NTPD.
There is already code for doing things like that on SIGHUP. We need
Hi,
I just realised something: LetsEncrypt certs are max 90 days. When I renew
them, will I need to restart NTPd?
So the max uptime of NTPd is 90 days? This does not matter now, when I am
doing a git pull, build, restart daily, but would it have an impact in
production?
Can the S2C code check
For what they're worth, my random thoughts are below...
On 4/11/19 4:31 AM, Hal Murray via devel wrote:
> There is a potential item: We may need the NTP server to listen on some port
> in addition to 123 in order to get around various filtering rules leftover
> from NTP DDoS amplification attack
I'm close to finishing cleaning up all the FIXMEs I had left behind.
What's next?
There are 2 major items on my list:
More and/or alternate certificate checking.
There are lots of possibilities in this area. I haven't found one that
looks clean and simple. We can afford modest amounts of
