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

Dave Hart davehart at gmail.com
Tue Sep 22 20:00:08 UTC 2009


On Tue, Sep 22, 2009 at 9:42 AM, Harlan Stenn wrote:
> 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?

My first choice would be no, keep -I and -L functionality essentially
the same (with both implementing ignore).  Anyone who prefers
listen-read-drop can start their rules in ntp.conf with an alternative
catchall rule:

nic drop all

That will prevent the implicit "nic ignore all" rule from ever coming
into play.

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

I think the folks who care about having ntpd listen on a subset of
available addresses are largely going to be usinig ntp.conf already,
and that is now the best place to manage listen/ignore/drop behavior.
The command-line switch approach is more relevant when all
configuration can be done via the command line, with no ntp.conf used,
as is the case for some broadcastclient configurations.  So I would
actually like to see -I and -L deprecated in the documentation now in
favor of using the configuration file rules, with an eye towards
reclaiming the -I and -L short option names for something else
someday.

> 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

In my opinion we shouldn't fiddle with deciding if the first explicit
rule is restrictive, but should simply always insert a default first
rule just before inserting the first explicit rule.  I don't see any
benefit to doing differently depending on the first rule's effect.

> 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.

As I mentioned in a bug 1315 comment a few minutes ago, anyone who
doesn't like the default rule doesn't have to use it.  They simply
need to effectively replace it with their own first "drop all" or
"listen all" rule.  As the last matching rule wins, any "all" rule
stops all searches from testing earlier rules such as the implicit
"nic ignore all".  There is an exception from "all" rules for loopback
addresses, which are excluded so that "ignore all" doesn't imply not
listening on the 127.0.0.1 and ::1 addresses used by local ntpq and
ntpdc.  Also, 127.0.0.1 is always listened on despite any rules to the
contrary, as ntp_intres depends on it for returning addresses resolved
from DNS names.  ::1 can be explicitly managed with "nic ignore ::1",
and the same will be true for 127.0.0.1 one ntp_intres is improved.

> 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.

I would really be disappointed if we require people to understand the
two flavors of "don't listen" before we allow them to configure ntpd
listen behavior using the preferred mechanism.  We should have a
single default rule, preferably "ignore all", but "drop all" would be
far better than requiring prior configuration of the default before
any other listen configuration.

Cheers,
Dave Hart


More information about the hackers mailing list