The pool command is simpler and more reliable than multiple server commands in ntp.conf. There is a lack of guidance for the pool command in the official documentation and the resources that are recommended are either not helpful or just wrong.

For example, the Server Commands and Options page (https://www.eecis.udel.edu/~mills/ntp/html/confopt.html) describes the pool command. Nowhere is there a mention on this page that a nopeer restriction (often set as default by installers) prevents pool from working. It is mentioned on the Access Control Commands and Options page (https://www.eecis.udel.edu/~mills/ntp/html/accopt.html#restrict), but there's no reason someone would think to look for it there. Someone trying to use pool for the first time with "restrict default nopeer" is presented with a .PEER. refid in ntpq, but is offered no clue as to why no peers actually show up. The Automatic Server Discovery Schemes page (https://www.eecis.udel.edu/~mills/ntp/html/discover.html#pool), suggested as a source of "additional information" about pool, also has no mention of nopeer.

Another link to pool command information on the Server Commands and Options page is to www.pool.ntp.org, which redirects to ntppool.org. Here, under How to Configure NTP for Use in the NTP Pool Project (https://news.ntppool.org/2017/05/how-to-configure-ntp-for-use-in-the-ntp-pool-project), sources of dubious and useless information are provided.

The first article (https://www.digitalocean.com/community/tutorials/how-to-configure-ntp-for-use-in-the-ntp-pool-project-on-ubuntu-16-04) is actually how to stop ntp from using pool. The author literally instructs the user to remove the pool commands in the default ntp.conf and replace them with server commands.

Before I move on, it is interesting to note that -- as this "documentation" describes -- Ubuntu's official repository provides a default ntp.conf that contains the following pool commands (that the "documentation" instructs us to remove):

pool 0.ubuntu.pool.ntp.org iburst
pool 1.ubuntu.pool.ntp.org iburst
pool 2.ubuntu.pool.ntp.org iburst
pool 3.ubuntu.pool.ntp.org iburst
pool ntp.ubuntu.com

This would, I think, produce as many as twenty time sources for the daemon. Mine (Ubuntu 22.04 LTS) created seventeen. In my experience, using over a dozen server commands for every client had previously been discouraged. Four might be alright. If I understand the point of pool, a single "pool ubuntu.pool.ntp.org" would be sufficient as a default configuration for a Linux distribution. Am I wrong to think that five such commands are excessive? And, if not, why would there be no guidance for the most prominent distributors of the daemon to write sane configurations?

And although using 0, 1, 2, etc., before the subdomain is needed for setting up several server commands for a pool, isn't the pool command there so that we can avoid that (in cases where only a few servers are sufficient, i.e.. almost all the time)? Why doesn't this example and many, many others like it on the Internet show any cognizance of that? The answer may be that no one is telling them how to use pool.

As for the second article on How to Configure NTP for Use in the NTP Pool Project (https://news.ntppool.org/2017/05/how-to-configure-ntp-for-use-in-the-ntp-pool-project), there is not a single mention of the pool command. This is the final suggested source of information on the pool command, following links from the official documentation.

Thus, both sources of information recommended by the official documentation to provide insight into how to use the pool command either discard or fail to acknowledge the existence of that command.

Please provide some useful documentation AND GUIDANCE for the pool command so that implementors, especially those that put ntp into repositories or, like Meinberg, make Windows versions, know that they should be using pool and how to use pool with restrict. And maybe put it in the official documentation somewhere where people can find it. And maybe ask ntppool.org to stop telling people not to use it?

Frank Wayne

I think you meant pool, not peer, in the subject...[more interleaved]

On 26/05/2022 22:22, Frank Wayne wrote:
>
> It is mentioned on the Access Control Commands and Options page (https://www.eecis.udel.edu/~mills/ntp/html/accopt.html#restrict), but there's no reason someone would think to look for it there. Someone trying to use pool for the first time with "restrict default nopeer" is presented with a .PEER. refid in ntpq, but is offered no clue as to why no peers actually show up.

If they hadn't looked there, they shouldn't have include a restrict
command in the first place.

> The first article (https://www.digitalocean.com/community/tutorials/how-to-configure-ntp-for-use-in-the-ntp-pool-project-on-ubuntu-16-04) is actually how to stop ntp from using pool. The author literally instructs the user to remove the pool commands in the default ntp.conf and replace them with server commands.

Which is quite correct in the context of the article, which is about
becoming a member of the pool, not a user. You don't want an incestuous
situation where pool members are getting their time from the pool.

>
> Before I move on, it is interesting to note that -- as this "documentation" describes -- Ubuntu's official repository provides a default ntp.conf that contains the following pool commands (that the "documentation" instructs us to remove):
>
> pool 0.ubuntu.pool.ntp.org iburst
> pool 1.ubuntu.pool.ntp.org iburst
> pool 2.ubuntu.pool.ntp.org iburst
> pool 3.ubuntu.pool.ntp.org iburst
> pool ntp.ubuntu.com
>
> This would, I think, produce as many as twenty time sources for the daemon. Mine (Ubuntu 22.04 LTS) created seventeen. In my experience, using over a dozen server

The way I read the documentation, the number actually used is capped.
However, I suspect this it he result of converting a server
configuration for using the pool, to the, newer, pool way, without
understanding the difference properly. Using "server" each line would
only pick one member of the pool specified, and repeated calls on the
same pool would likely get the same one over and over.

> why would there be no guidance for the most prominent distributors of the daemon to write sane configurations?

People who package for Linux distributions often aren't power users of
the packages. Although the following example isn't NTP, one also gets
the problem of copying and pasting, which propagates misunderstandings,
when people who should have read the documentation in detail have just
copied someone else's solution, with minor tweak. Where I see this is
configuration for access internet telephony service providers in the
Asterisk PABX. They are invariable half nonsense.

Anyway, I guess the real problem here is that the only maintained
documentation is reference documentation, and there isn't a good set of
cook book documentation.
>

On Thursday, May 26, 2022 at 5:18:31 PM UTC-5, David Woolley wrote:
> I think you meant pool, not peer, in the subject...[more interleaved]

(Argh.) Yes, I meant "pool".

> On 26/05/2022 22:22, Frank Wayne wrote:
> >
> > It is mentioned on the Access Control Commands and Options page (https://www.eecis.udel.edu/~mills/ntp/html/accopt.html#restrict), but there's no reason someone would think to look for it there. Someone trying to use pool for the first time with "restrict default nopeer" is presented with a .PEER. refid in ntpq, but is offered no clue as to why no peers actually show up.
> If they hadn't looked there, they shouldn't have include a restrict
> command in the first place.

Agreed, but Meinberg's build for Windows and at least one FreeBSD server I have already had restrict in the configuration at install, so the user isn't the one including it. Furthermore, there are a lot of examples in search results that include or urge the use of restrict.

> > why would there be no guidance for the most prominent distributors of the daemon to write sane configurations?
> People who package for Linux distributions often aren't power users of
> the packages.

Yes, and their packages affect millions of systems. It would be nice to help them understand it better somehow. :)

> Anyway, I guess the real problem here is that the only maintained
> documentation is reference documentation, and there isn't a good set of
> cook book documentation.

Hear, hear!