Harlan Stenn wrote:
Greg Troxel writes:
Harlan Stenn <st...@ntp.org> writes:
William Unruh writes:
I do not mean the default in the config file, I mean the default if
there is no config file or if nothing is set in the config file.
Then ntpd won't connect to anything and there will be no data to report.
This is a ridiculous strawman. The ntp project is abdicating its
responsibility to provide sane default behavior by claiming that no
default behavior can make everyone happy and therefore it's not their
fault. The notion that OS packagers somehow have a better idea of usage
is also specious.
We do supply some sample config files in the conf/ directory.
>
I don't know that anybody is really happy about them.
I've just looked at these in current ntp-dev and found that there are
only config files from some test machines at udel, with very specific
configuration options. So these are not good examples for
I am disinclined to distribute files like that because they "stick
around" for far too long.
I don't even believe those config files are still appropriate for
current versions of ntpd and real configurations of current test
machines, so I think they could simply be removed, at least from the
published tarballs.
On the other hand, if I look at the ntp.conf files shipped e.g. with
different Linux distros I can see that most configurations try to
achieve the same goal, e.g. make information available via mode 6 or
mode 7 packets only available to localhost.
As mentioned in some other post here, the task to set up a "safe"
default configuration has to be done multiple times by different folks
at different OS vendors.
In fact the maintenance effort for OS vendors would be much easier if
the original NTP tarball was shipped with a "safe" configuration.
Otherwise the "safety" of a default configuration depends strongly on
the level of knowledge the NTP package maintainer of a particular OS
vendor has.
So if ntpd should not be shipped with a sample config file then I agree
the default config file to be maintained by the OS vendors should be as
simple as possible to yield a "safe" configuration, as someone else has
already mentioned.
For example, if the default restrictions built into ntpd would be to
allow monitoring requests only from local host then no "restrict"
statements might be required in a simple default configuration file. OS
vendors could just provide a file with some default servers, like it is
actually common practice for some Linux distros.
E.g. Fedora and Debian use pool configurations like
server 0.fedora.pool.ntp.org iburst
or
server 0.debian.pool.ntp.org iburst
with current stable ntpd.
Sophisticated users who want some "extra" configuration could add some
lines similar as they already have to do right now, e.g. if they want to
use some specific refclock.
It should not be too hard to change ntpd such that the default
restrictions match what most admins would set up anyway.
And 4.2.8 would be a good step for such change, similar as the default
logging has changed from 4.2.4 to 4.2.6.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
