[ntp:questions] Re: "Listen on" semantics
maarten at kittensandcats.net
Fri Sep 22 11:58:18 UTC 2006
"Danny Mayer" <mayer at ntp.isc.org> wrote in message
news:4513531A.1080902 at ntp.isc.org...
> Maarten Wiltink wrote:
>> "Luc Pardon" <xntp at skopos.be> wrote in message
>> news:45110BAE.8040106 at skopos.be...
>>> What I want is not so much two copies of ntpd as a separation
>>> between client and server functionality.
>>> The client should keep my clock on track. The server should
>>> tell all my other systems what time it is.
>> [...] Never any time for redesigns like this.
> I would like to understand what we'd be redesigning? You set up your
> servers, you set up your restrictions and you are done. It works, you
> can authenticate the servers, you can provide authentication to YOUR
> clients and there's nothing else to do. Dropping packets can be done at
> a firewall.
Separation of client and server functionality, with corresponding
separation of use of client and server sockets. The ability to _never_
open a server socket on the red interface.
Restrictions may actually be a better mechanism, but I can't stop
thinking of a review of some Linux distribution I read years ago.
Every network application had been split into two packages: a client
part and a server part. No configuration necessary, you could install
the client and never worry about inadvertently running the server, too.
Between client, server, _and ntpq_, however, I'm not sure anymore life
is that easy. The server module probably has to be told whether to serve
time and/or status; before long you'll have strongly coupled modules and
the full functionality of restrictions and you've won nothing.
More information about the questions