[ntp:hackers] -I, -L, and the new nic/interface config stuff

Harlan Stenn stenn at ntp.org
Tue Sep 22 09:42:26 UTC 2009


Folks,

Once upon a time folks wanted a way to "not listen" to certain IPs
and/or interfaces.

As I recall (and corrections are welcome)...

We knew this was gonna be difficult to get right in the config file and
we knew it was gonna take a while before we had a useful plan.

In the interim we came up with two partial workarounds.

One was -L, that said "do not listen to virtual IPs".  The definition of
a virtual IP was one that had a ':' in the name, which meant it only
worked on Linux and Solaris boxes.

The other was -I, that said "listen on the <arg>".

For better or worse, with -L under this scheme we would ignore any of
the IPs that "matched", and for -I (in ntp-stable only *one* -I flag is
allowed) anything that doesn't match is open-read-dropped.

Now that we are about to release code in 4.2.6 that appears to offer a
complete mechanism to offer what seems to be adequate to implement all
of the policy choices of listen|open-read-drop|ignore for interfaces
and/or IPs, we find there are some corner cases that need to be
addressed.  To see the scenarios and some discussion, please visit
https://support.ntp.org/bin/view/Dev/NtpdAndNetworkSockets (and if you
think you have a use-case that is not covered, please add it).

First, given that -L only worked for 2 OSes and implemented "ignore"
policy and -I only supported one instance and implemented "drop" policy,
is there any reason we should let folks specify the complete interface
control mechanism on the command line?

If not, what about completely removing the -I and -L options instead?

Second, we need to decide what to about interfaces and IPs that are
*not* covered by any stated directives.  I see the following choices in
the case where the first "interface" ntp.conf file contans a
"restrictive" listen directive:

- use 'nic drop all' before the specified 'listen' directive
- use 'nic ignore all' before the specified 'listen' directive
- signal an error

My belief is that if we use either of the first two we will find vocal
opponents of whatever choice we make and if we decide our initial
choicee wass wrong it will be Difficult to change that default later.

If we use the 3rd choice, we are requiring people to (try to) understand
the issues well enough to make a good decision.  Granted, we can do our
best to document this, but hey, documentation can always be better and
sysadmins may or may not decide to read it.

So let's discuss...

-- 
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!


More information about the hackers mailing list