Created attachment 159128 [details] Add pool configuration and dynamic source restrictions For the past several years, current versions of ntpd have included some very smart enhancements for using the pool servers. Now, at last, FreeBSD can do this too. The attached patch enables that functionality. 1. Replace 'server' statements with 'pool' statements. 'server' configures a PERSISTENT association with a SINGLE server from the IP addresses returned from the pool DNS name. 'pool' configures PREEMPTIVE associations with MULTIPLE servers from the IP addresses returned from the pool DNS name. 'pool' gives us a dynamic set of upstream servers: servers which become unreliable or unreachable are discarded and new ones configured automatically from whatever the current set of IP addresses for that pool DNS name happens to be. 2. Remove superfluous 'restrict -6' statements. 'restrict' statements which do not include addresses or masks apply to both IPv4 and IPv6. 3. Introduce 'restrict source' statement to provide . 'restrict source' provides default restrictions for upstream time servers. When a new pool server is selected, a new 'restrict' entry will be created for that server from this template. When a configured server is dropped, its dynamic 'restrict' entry is deleted. 4. Remove text and examples for discreet server'restrict' statements. Since explicit server 'restrict' statements are not required with this sample rc.conf, I suggest that this is superfluous and confusing. I guess it depends on whether the file is meant to be a tutorial or just a working sample. 5. Move the local clock 'restrict' sample down to the section dealing with the local clock. The following is from a running server (i386 10.2-BETA2 r285783) using the patched configuration. The patch provided is against stable/10 r285783. rwsrv02> ntpq -np remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.004 1.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.004 2.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.004 +125.255.139.115 130.194.1.96 2 u 29 128 377 43.096 -4.175 0.423 *203.23.237.200 203.35.83.242 2 u 32 128 377 29.844 -3.550 0.693 -121.0.0.42 23.31.237.112 3 u 90 256 377 46.560 -2.756 0.850 +54.252.165.245 202.21.137.10 2 u 30 128 377 30.060 -4.859 1.264 -2001:418:3ff::1 204.123.2.72 2 u 43 256 377 173.324 -1.592 1.937 -2001:df0:fe:2:: 130.102.2.123 3 u 242 256 377 44.177 4.080 3.433 -130.102.2.123 216.218.254.202 2 u 27 128 377 46.288 -4.332 0.780 rwsrv02>
I would like to see this in 10.2.
I think this discussion should be moved to phabricator.
I just stumbled across this; I updated ntp.conf to use the pool keyword last year, without realizing this PR was here. I didn't realize until finding this that the -4/-6 flags had become meaningless in ntp.conf. I've opened a phabricator review to make that part of your changes to ntp.conf https://reviews.freebsd.org/D15974
A commit references this bug: Author: ian Date: Sun Jun 24 03:29:01 UTC 2018 New revision: 335595 URL: https://svnweb.freebsd.org/changeset/base/335595 Log: Modernize usage of "restrict" keyword in ntp.conf It is no longer necessary to specify a -4/-6 flag on any ntp.conf keyword. The address type is inferred from the address itself as necessary. "restrict default" statements always apply to both address families regardless of any -4/-6 flag that may be present. So this change just tidies up our default config by removing the redundant restrict -6 statement and comment, and by removing the -6 flag from the restrict keyword that allows access from localhost. This change was inspired by the patches provided in PRs 201803 and 210245, and included some contrib/ntp code inspection to verify that the -4/-6 keywords are basically no-ops in all contexts now. PR: 201803 210245 Differential Revision: https://reviews.freebsd.org/D15974 Changes: head/etc/ntp.conf
A commit references this bug: Author: ian Date: Wed Jul 4 14:04:23 UTC 2018 New revision: 335949 URL: https://svnweb.freebsd.org/changeset/base/335949 Log: MFC r335595-r335596 r335595: Modernize usage of "restrict" keyword in ntp.conf It is no longer necessary to specify a -4/-6 flag on any ntp.conf keyword. The address type is inferred from the address itself as necessary. "restrict default" statements always apply to both address families regardless of any -4/-6 flag that may be present. So this change just tidies up our default config by removing the redundant restrict -6 statement and comment, and by removing the -6 flag from the restrict keyword that allows access from localhost. This change was inspired by the patches provided in PRs 201803 and 210245, and included some contrib/ntp code inspection to verify that the -4/-6 keywords are basically no-ops in all contexts now. PR: 201803 210245 Differential Revision: https://reviews.freebsd.org/D15974 r335596: Fix a comment; the ntp leaplist file is updated periodically, but not weekly (it's only updated when a check shows it's within 30 days of expiring). PR: 207138 Changes: _U stable/11/ stable/11/etc/ntp.conf
A commit references this bug: Author: ian Date: Wed Jul 4 14:10:36 UTC 2018 New revision: 335950 URL: https://svnweb.freebsd.org/changeset/base/335950 Log: MFC r335595-r335596 r335595: Modernize usage of "restrict" keyword in ntp.conf It is no longer necessary to specify a -4/-6 flag on any ntp.conf keyword. The address type is inferred from the address itself as necessary. "restrict default" statements always apply to both address families regardless of any -4/-6 flag that may be present. So this change just tidies up our default config by removing the redundant restrict -6 statement and comment, and by removing the -6 flag from the restrict keyword that allows access from localhost. This change was inspired by the patches provided in PRs 201803 and 210245, and included some contrib/ntp code inspection to verify that the -4/-6 keywords are basically no-ops in all contexts now. PR: 201803 210245 Differential Revision: https://reviews.freebsd.org/D15974 r335596: Fix a comment; the ntp leaplist file is updated periodically, but not weekly (it's only updated when a check shows it's within 30 days of expiring). PR: 207138 Changes: _U stable/10/ stable/10/etc/ntp.conf