[PATCH] The NTP client/server applet

[Denys Vlasenko]

On Mon, Nov 23, 2009 at 1:57 PM, Adam Tkac <vonsch at gmail.com> wrote:
> I agree with all your changes except one piece below.
>
> Admins usually use "NTP pool" as the main time source (pool.ntp.org).
> With your patch only one server is used. I know the old version of
> add_peers consumes more space (+241B) but on the other hand it makes
> ntpd more accurate.

They have a pool of machines with many IPs but one DNS name?
Not one machine?

I see. Since for NTP it can be done, they decided that this
setup would be is neat, and did it.
But neatness not necessarily equals usefulness.

Think about how multi-IP hostnames work.

ping google.com  - which IP will ping select? It can't ping them all,
that would be weird (and harder to implement).

ssh multihomed.org - which IP will ssh select? It can't use
more than one at once for sure!

wget http://multihomed.org/  - which IP .... ?

See? Almost always, when you give a hostname, it does not make sense
to "explode" it into *many* IPs, you want *one* IP.

Thus, it makes sense to just follow this model always.
When you have a hostname -> IP translation, return *one* IP.

Either DNS servers or DNS resolver in libc may give
this IP semi-randomly from the set of available IPs
for that hostname, in order to load-balance it, but that's
about it.

Getting fancy and hiding *several* servers (to be treated
as separate servers, not a cluster) behind one hostname
breaks this simple concept. So whoever is doing it
did not think whether cool factor is worth resulting PITA.

I think this was a stupid idea.

For one, what if someone else has a *single* NTP server,
which just happens to have 27 addresses? ntpd
will erroneously think that there are 27 peers
at that hostname!!!

If they want to have a pool of machines,
srv1.pool.ntp.org, srv2.pool.ntp.org, srv3.pool.ntp.org
would have worked just fine.

Having said that, we'd probably need to support that
stupid thing now, it's out of our control to fix it...
--
vda