[ntp:questions] Re: "Listen on" semantics
mayer at ntp.isc.org
Mon Sep 25 02:32:55 UTC 2006
Maarten Wiltink wrote:
> "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.
There's no practical meaning to this statement. There is no such think
as a server socket or a client socket. There is only a socket.
> 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.
Some things are easy to split, such as brower from HTTP server, for
example, and some it makes no sense. ntpd falls into the latter case.
> 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.
> Maarten Wiltink
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions