Sad Clouds <cryintothebluesky%gmail.com@localhost> writes: > On Sun, 11 Oct 2020 12:49:16 +0200 (CEST) > Havard Eidnes <he%NetBSD.org@localhost> wrote: > >> > The question is whether we ought to do something to break this >> > circular dependency in our default install by specifying one or two >> > (depending on "minsane" and resiliency conciderations) ntp servers >> > via IP address? The issue then becomes "which IP address(es)" and >> > "how can that scale"? >> >> ...or improve the documentation for potentially RTC-less systems >> about the rc.conf ntpdate_hosts workaround. >> >> Regards, >> >> - Håvard > > If you look at /etc/rc.d/ntpdate script, it checks if "ntpdate_hosts" > is empty and if yes, attempts to extract hosts from /etc/ntp.conf > > I would suggest adding the following logic: > > 1. Extract hosts and check if they are hostnames and not IP addresses. > > 2. Attempt to resolve each one of them. If they all fail, fall back to > hardcoded list of IP addresses that point to public NTP servers. > > The hardcoded NTP servers list would need to be something that is not > likely to have their IP addresses changed and are always available, > similar to CloudFlare or Google public DNS servers. This is not 100% > full proof, but should work for any machine that is able to route > NTP packets to the Internet. > > The man page for ntpdate talks about NetInfo support. No idea what this > is (maybe somehow similar to SRV records?), but if this is enabled, NTP > server name/IP can be omitted and ntpdate somehow finds suitable one > automagically. This probably still needs fully working DNS service. I would rather not add this magic code, and also not configure addresses like these. To me this is a special case of running NetBSD on an RTC-less machine, which I see as a bit irregular. It's really a problem for deployed machines without console access. It would be fair to point this out in the raspberry pi howto, though.
Attachment:
signature.asc
Description: PGP signature