Re: ntpd.conf.5 duplicate word
On Wed, Jan 06, 2021 at 08:53:04PM +0800, Sean Davies wrote: > Index: ntpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v > retrieving revision 1.46 > diff -u -p -u -r1.46 ntpd.conf.5 > --- ntpd.conf.5 16 May 2020 16:58:12 -0000 1.46 > +++ ntpd.conf.5 6 Jan 2021 12:41:49 - > @@ -119,7 +119,7 @@ sensor udcf0 correction 7 > A > .Ic refid > .Ar ID-string > -of up up to 4 ASCII characters can be > +of up to 4 ASCII characters can be > given to publish the sensor type to clients. > RFC 2030 suggests some common reference identifiers, but new identifiers > "can be contrived as appropriate." > > -- > Sean > fixed, thanks. jmc
ntpd.conf.5 duplicate word
Index: ntpd.conf.5 === RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v retrieving revision 1.46 diff -u -p -u -r1.46 ntpd.conf.5 --- ntpd.conf.5 16 May 2020 16:58:12 - 1.46 +++ ntpd.conf.5 6 Jan 2021 12:41:49 - @@ -119,7 +119,7 @@ sensor udcf0 correction 7 A .Ic refid .Ar ID-string -of up up to 4 ASCII characters can be +of up to 4 ASCII characters can be given to publish the sensor type to clients. RFC 2030 suggests some common reference identifiers, but new identifiers "can be contrived as appropriate." -- Sean
Re: [PATCH] correcting in-sane ntpd.conf
Tim Kuijsten wrote: > > Nor do you bring up the traffic to the IP addresses offered by > > pool.ntp.org. That traffic has a pattern easily distinguished as > > "system startup". > > > > What's the difference? There isn't. Yet you brought up only google. > > I can understand why someone would be ok with sending some packets > to small players like pool.ntp.org and not be ok with sending packets > to extremely big and powerful companies that are in the business > of surveillance capitalism. Divide and conquer! So you have no justification at all.
Re: [PATCH] correcting in-sane ntpd.conf
On 2019/12/09 13:16, Tim Kuijsten wrote: > > Nor do you bring up the traffic to the IP addresses offered by > > pool.ntp.org. That traffic has a pattern easily distinguished as > > "system startup". > > > > What's the difference? There isn't. Yet you brought up only google. > > I can understand why someone would be ok with sending some packets > to small players like pool.ntp.org and not be ok with sending packets > to extremely big and powerful companies that are in the business > of surveillance capitalism. Divide and conquer! > I don't see how pool.ntp.org can be described as a small player when it comes to public NTP servers? 3 of the 4 hosts I currently get from them are large transit ISPs (NTT, TATA, Interoute). Plus of course you have no idea in advance who you are getting. If you are concerned about people using this information to evaluate things like how many machines you have running OpenBSD or how often they reboot, run your own NTP server with an internet upstream and point clients there. Or if you don't want people on the network path between you and public NTP servers to figure out that you're running OpenBSD at all from your time queries, GNSS modules are pretty cheap nowadays so you can run your own stratum 1 easily enough.
Re: [PATCH] correcting in-sane ntpd.conf
> Nor do you bring up the traffic to the IP addresses offered by > pool.ntp.org. That traffic has a pattern easily distinguished as > "system startup". > > What's the difference? There isn't. Yet you brought up only google. I can understand why someone would be ok with sending some packets to small players like pool.ntp.org and not be ok with sending packets to extremely big and powerful companies that are in the business of surveillance capitalism. Divide and conquer!
Re: [PATCH] correcting in-sane ntpd.conf
>I meant that as a privacy concern that some users might not be aware of. What privacy concern? You don't bring up privacy concerns with DNS lookup of pool.ntp.org. Nor do you bring up the traffic to the IP addresses offered by pool.ntp.org. That traffic has a pattern easily distinguished as "system startup". What's the difference? There isn't. Yet you brought up only google. If you don't want people to know you are running a ntp server, then don't run a ntp server. >As a way of solving that problem one could suggest and point a finger >explicitly on the default ntpd.conf. Unless there are great reasons to do otherwise, we ship turn-key systems. >Reasons ? A privacy concern that most users won't be aware of. >I might have understood you wrong, otto. Please correct me. I think you are tilting at windmills.
Re: [PATCH] correcting in-sane ntpd.conf
I meant that as a privacy concern that some users might not be aware of. As a way of solving that problem one could suggest and point a finger explicitly on the default ntpd.conf. Reasons ? A privacy concern that most users won't be aware of. I might have understood you wrong, otto. Please correct me. g Stephan On Sun, Dec 08, 2019 at 10:36:18AM +0100, Otto Moerbeek wrote: > On Sun, Dec 08, 2019 at 11:15:55AM +0100, List wrote: > > > Please excuse that I wasted your time. You're absolutely right. > > > > The only thing that comes to my mind is that one could add something > > like a small notice that tells the new user to maybe alter his ntpd > > constraints to a "TLS-Provider" that resides in his time zone. > > A good place for that could be the welcoming mail, which already > > describes some first steps. > > Why? You can travel the internet many times around and still be withing > the bounds the constraint checking allows. As for response time, google > anycast is pretty good at that. > > -Otto > > > > > > > On Sat, Dec 07, 2019 at 11:25:48AM -0700, Theo de Raadt wrote: > > > >That might be the case. > > > >The man page creates the impression that my ntpd will carry out a TLS > > > >Handshake with "https://www.google.com";. Out of that handshake (because > > > >it is anycast) you get your approximate local time. Which serves as > > > >vague measuring point for answers by the ntp servers that you are > > > >querying. But the suggestion I made is absolutely 100 % wrong. > > > > > > > >Would it be an option to choose another Anycast resolving address ? > > > >For example akami.net ? > > > > > > akami.net has no https. > > > maybe you mean akamai.net? again, no https. > > > > > > many akamai services come out of less capable caches, not making the > > > same effective certificate promises as the google front-end. would > > > you notice if an akamai service did a certificate downgrade? not > > > really. i don't think the proposal is serious. > > > > > > as a result we use quad9 and google https because their global > > > adjacency is excellent, and then we are avoiding cloudflare https > > > because we added their ticker in the mix (though their anycast ticker > > > is a very weird thing) > > > > > > >g Stephan > > > > > > > >On Thu, Dec 05, 2019 at 03:03:43PM -0700, Theo de Raadt wrote: > > > >> I guess you don't understand what is going on there. > > > >> > > > >> List wrote: > > > >> > > > >> > Hello, > > > >> > > > > >> > here a diff replacing www.google.com as a default time constraint by > > > >> > www.openbsd.org. > > > >> > It is claimed that OpenBSD would have sane and secure defaults. While > > > >> > www.google.com might be secure it ain't sane from a privacy concerned > > > >> > perspective. Therefore the diff. > > > >> > > > > >> > Regards, > > > >> > Stephan > > > >> > > > > >> > Index: etc/ntpd.conf > > > >> > === > > > >> > RCS file: /cvs/src/etc/ntpd.conf,v > > > >> > retrieving revision 1.16 > > > >> > diff -u -p -r1.16 ntpd.conf > > > >> > --- etc/ntpd.conf 6 Nov 2019 19:04:12 - 1.16 > > > >> > +++ etc/ntpd.conf 5 Dec 2019 21:36:57 - > > > >> > @@ -8,4 +8,4 @@ sensor * > > > >> > > > > >> > constraint from "9.9.9.9" # quad9 v4 without DNS > > > >> >constraint from "2620:fe::fe" # quad9 v6 without DNS > > > >> >-constraints from "www.google.com" # intentionally not > > > >> > 8.8.8.8 > > > >> >+constraints from "www.openbsd.org" # intentionally not > > > >> > Google > > > >> > > > > >> > > > > > > >
Re: [PATCH] correcting in-sane ntpd.conf
On Sun, Dec 08, 2019 at 11:15:55AM +0100, List wrote: > Please excuse that I wasted your time. You're absolutely right. > > The only thing that comes to my mind is that one could add something > like a small notice that tells the new user to maybe alter his ntpd > constraints to a "TLS-Provider" that resides in his time zone. > A good place for that could be the welcoming mail, which already > describes some first steps. Why? You can travel the internet many times around and still be withing the bounds the constraint checking allows. As for response time, google anycast is pretty good at that. -Otto > > > On Sat, Dec 07, 2019 at 11:25:48AM -0700, Theo de Raadt wrote: > > >That might be the case. > > >The man page creates the impression that my ntpd will carry out a TLS > > >Handshake with "https://www.google.com";. Out of that handshake (because > > >it is anycast) you get your approximate local time. Which serves as > > >vague measuring point for answers by the ntp servers that you are > > >querying. But the suggestion I made is absolutely 100 % wrong. > > > > > >Would it be an option to choose another Anycast resolving address ? > > >For example akami.net ? > > > > akami.net has no https. > > maybe you mean akamai.net? again, no https. > > > > many akamai services come out of less capable caches, not making the > > same effective certificate promises as the google front-end. would > > you notice if an akamai service did a certificate downgrade? not > > really. i don't think the proposal is serious. > > > > as a result we use quad9 and google https because their global > > adjacency is excellent, and then we are avoiding cloudflare https > > because we added their ticker in the mix (though their anycast ticker > > is a very weird thing) > > > > >g Stephan > > > > > >On Thu, Dec 05, 2019 at 03:03:43PM -0700, Theo de Raadt wrote: > > >> I guess you don't understand what is going on there. > > >> > > >> List wrote: > > >> > > >> > Hello, > > >> > > > >> > here a diff replacing www.google.com as a default time constraint by > > >> > www.openbsd.org. > > >> > It is claimed that OpenBSD would have sane and secure defaults. While > > >> > www.google.com might be secure it ain't sane from a privacy concerned > > >> > perspective. Therefore the diff. > > >> > > > >> > Regards, > > >> > Stephan > > >> > > > >> > Index: etc/ntpd.conf > > >> > === > > >> > RCS file: /cvs/src/etc/ntpd.conf,v > > >> > retrieving revision 1.16 > > >> > diff -u -p -r1.16 ntpd.conf > > >> > --- etc/ntpd.conf 6 Nov 2019 19:04:12 - 1.16 > > >> > +++ etc/ntpd.conf 5 Dec 2019 21:36:57 - > > >> > @@ -8,4 +8,4 @@ sensor * > > >> > > > >> > constraint from "9.9.9.9" # quad9 v4 without DNS > > >> >constraint from "2620:fe::fe" # quad9 v6 without DNS > > >> >-constraints from "www.google.com" # intentionally not 8.8.8.8 > > >> >+constraints from "www.openbsd.org" # intentionally not Google > > >> > > > >> > > > >
Re: [PATCH] correcting in-sane ntpd.conf
Please excuse that I wasted your time. You're absolutely right. The only thing that comes to my mind is that one could add something like a small notice that tells the new user to maybe alter his ntpd constraints to a "TLS-Provider" that resides in his time zone. A good place for that could be the welcoming mail, which already describes some first steps. On Sat, Dec 07, 2019 at 11:25:48AM -0700, Theo de Raadt wrote: > >That might be the case. > >The man page creates the impression that my ntpd will carry out a TLS > >Handshake with "https://www.google.com";. Out of that handshake (because > >it is anycast) you get your approximate local time. Which serves as > >vague measuring point for answers by the ntp servers that you are > >querying. But the suggestion I made is absolutely 100 % wrong. > > > >Would it be an option to choose another Anycast resolving address ? > >For example akami.net ? > > akami.net has no https. > maybe you mean akamai.net? again, no https. > > many akamai services come out of less capable caches, not making the > same effective certificate promises as the google front-end. would > you notice if an akamai service did a certificate downgrade? not > really. i don't think the proposal is serious. > > as a result we use quad9 and google https because their global > adjacency is excellent, and then we are avoiding cloudflare https > because we added their ticker in the mix (though their anycast ticker > is a very weird thing) > > >g Stephan > > > >On Thu, Dec 05, 2019 at 03:03:43PM -0700, Theo de Raadt wrote: > >> I guess you don't understand what is going on there. > >> > >> List wrote: > >> > >> > Hello, > >> > > >> > here a diff replacing www.google.com as a default time constraint by > >> > www.openbsd.org. > >> > It is claimed that OpenBSD would have sane and secure defaults. While > >> > www.google.com might be secure it ain't sane from a privacy concerned > >> > perspective. Therefore the diff. > >> > > >> > Regards, > >> > Stephan > >> > > >> > Index: etc/ntpd.conf > >> > === > >> > RCS file: /cvs/src/etc/ntpd.conf,v > >> > retrieving revision 1.16 > >> > diff -u -p -r1.16 ntpd.conf > >> > --- etc/ntpd.conf 6 Nov 2019 19:04:12 - 1.16 > >> > +++ etc/ntpd.conf 5 Dec 2019 21:36:57 - > >> > @@ -8,4 +8,4 @@ sensor * > >> > > >> > constraint from "9.9.9.9" # quad9 v4 without DNS > >> >constraint from "2620:fe::fe" # quad9 v6 without DNS > >> >-constraints from "www.google.com" # intentionally not 8.8.8.8 > >> >+constraints from "www.openbsd.org" # intentionally not Google > >> > > >> > >
Re: [PATCH] correcting in-sane ntpd.conf
I guess you don't understand what is going on there. List wrote: > Hello, > > here a diff replacing www.google.com as a default time constraint by > www.openbsd.org. > It is claimed that OpenBSD would have sane and secure defaults. While > www.google.com might be secure it ain't sane from a privacy concerned > perspective. Therefore the diff. > > Regards, > Stephan > > Index: etc/ntpd.conf > === > RCS file: /cvs/src/etc/ntpd.conf,v > retrieving revision 1.16 > diff -u -p -r1.16 ntpd.conf > --- etc/ntpd.conf 6 Nov 2019 19:04:12 - 1.16 > +++ etc/ntpd.conf 5 Dec 2019 21:36:57 - > @@ -8,4 +8,4 @@ sensor * > > constraint from "9.9.9.9" # quad9 v4 without DNS >constraint from "2620:fe::fe" # quad9 v6 without DNS >-constraints from "www.google.com" # intentionally not 8.8.8.8 >+constraints from "www.openbsd.org" # intentionally not Google >
[PATCH] correcting in-sane ntpd.conf
Hello, here a diff replacing www.google.com as a default time constraint by www.openbsd.org. It is claimed that OpenBSD would have sane and secure defaults. While www.google.com might be secure it ain't sane from a privacy concerned perspective. Therefore the diff. Regards, Stephan Index: etc/ntpd.conf === RCS file: /cvs/src/etc/ntpd.conf,v retrieving revision 1.16 diff -u -p -r1.16 ntpd.conf --- etc/ntpd.conf 6 Nov 2019 19:04:12 - 1.16 +++ etc/ntpd.conf 5 Dec 2019 21:36:57 - @@ -8,4 +8,4 @@ sensor * constraint from "9.9.9.9" # quad9 v4 without DNS constraint from "2620:fe::fe" # quad9 v6 without DNS -constraints from "www.google.com" # intentionally not 8.8.8.8 +constraints from "www.openbsd.org" # intentionally not Google
Re: ntpd.conf
On Wed, Dec 28, 2016 at 09:59:06PM +0100, Jan Stary wrote: > Markup a forgotten keyword. > > Jan > fixed, thanks. jmc > Index: ntpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v > retrieving revision 1.33 > diff -u -p -r1.33 ntpd.conf.5 > --- ntpd.conf.5 23 Oct 2015 14:52:20 - 1.33 > +++ ntpd.conf.5 28 Dec 2016 20:58:06 - > @@ -127,7 +127,9 @@ sensor nmea0 refid GPS > .Ed > .Pp > A stratum value other than the default of 1 can be assigned using > -the stratum keyword. > +the > +.Ic stratum > +keyword. > .It Xo Ic server Ar address > .Op Ic weight Ar weight-value > .Xc >
ntpd.conf
Markup a forgotten keyword. Jan Index: ntpd.conf.5 === RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v retrieving revision 1.33 diff -u -p -r1.33 ntpd.conf.5 --- ntpd.conf.5 23 Oct 2015 14:52:20 - 1.33 +++ ntpd.conf.5 28 Dec 2016 20:58:06 - @@ -127,7 +127,9 @@ sensor nmea0 refid GPS .Ed .Pp A stratum value other than the default of 1 can be assigned using -the stratum keyword. +the +.Ic stratum +keyword. .It Xo Ic server Ar address .Op Ic weight Ar weight-value .Xc
Re: ntpd.conf and Google
On 01/13/2016 06:10 AM, Theo de Raadt wrote: $ fgrep constraint /etc/ntpd.conf constraints from "https://www.google.com"; $ www.google.com and other Google services are not accessible from countries like China or Vietnam. It's easy enough for people to change their ntpd.conf if necessary but how about using a default value that is more likely to work for everyone? Something like https://www.un.org/ for example. That looks like a centralized service operated on a single provider network without global load balancing "features", the DNS TTL alone hints this would be unsuitable. Probably not built to the same scale, does not feel right to me. There are are a lot of variables involved in making a selection, and the result is certainly imperfect. I get where you are coming from, but you can probably see why we currently choose what we do. What about using https://www.akamai.com? smime.p7s Description: S/MIME Cryptographic Signature
Re: ntpd.conf and Google
> $ fgrep constraint /etc/ntpd.conf > constraints from "https://www.google.com"; > $ > > www.google.com and other Google services are not accessible from > countries like China or Vietnam. It's easy enough for people to > change their ntpd.conf if necessary but how about using a default > value that is more likely to work for everyone? Something like > https://www.un.org/ for example. That looks like a centralized service operated on a single provider network without global load balancing "features", the DNS TTL alone hints this would be unsuitable. Probably not built to the same scale, does not feel right to me. There are are a lot of variables involved in making a selection, and the result is certainly imperfect. I get where you are coming from, but you can probably see why we currently choose what we do.
ntpd.conf and Google
Hello, $ fgrep constraint /etc/ntpd.conf constraints from "https://www.google.com"; $ www.google.com and other Google services are not accessible from countries like China or Vietnam. It's easy enough for people to change their ntpd.conf if necessary but how about using a default value that is more likely to work for everyone? Something like https://www.un.org/ for example. Cheers, Philippe
reference ntpctl in ntpd.conf.5
This is similar to what is done for relayd and snmpd, etc. Index: ntpd.conf.5 === RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v retrieving revision 1.31 diff -u -p -r1.31 ntpd.conf.5 --- ntpd.conf.5 18 May 2015 11:10:03 - 1.31 +++ ntpd.conf.5 28 Aug 2015 02:44:59 - @@ -223,6 +223,7 @@ default configuration file .El .Sh SEE ALSO +.Xr ntpctl 8 , .Xr ntpd 8 , .Xr sysctl 8 .Sh HISTORY
Re: man ntpd.conf: small errors in constraints section
On Sat, Feb 14, 2015 at 05:16:49PM +0100, Max Fillinger wrote: > Some small issues in the new section: > > - 'NTP servers' means actual servers, not the keyword, so remove the .Ic > > - 'constraint' is used instead of 'constraint from' in some places; that > might be ok as an abbreviation, but at least the example should use > the full keyword. In the diff below, I used 'constraint from' > everywhere. > fixed, thanks. jmc > Index: usr.sbin/ntpd/ntpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v > retrieving revision 1.27 > diff -u -p -r1.27 ntpd.conf.5 > --- usr.sbin/ntpd/ntpd.conf.5 10 Feb 2015 19:21:16 - 1.27 > +++ usr.sbin/ntpd/ntpd.conf.5 14 Feb 2015 15:55:54 - > @@ -188,24 +188,23 @@ thereby reducing the impact of unauthent > attacks. > Received NTP packets with time information falling outside of a range > near the constraint will be discarded and such NTP > -.Ic servers > -will be marked as invalid. > +servers will be marked as invalid. > .Bl -tag -width Ds > .It Ic constraint from Ar url > Specify the URL, IP address or the hostname of an HTTPS server to > provide a constraint. > If multiple > -.Ic constraint > +.Ic constraint from > keywords are used, > .Xr ntpd 8 > will calculate a median constraint from all the servers specified. > .Bd -literal -offset indent > server ntp.example.org > -constraint www.example.com > +constraint from www.example.com > .Ed > .It Ic constraints from Ar url > As with > -.Ic constraint , > +.Ic constraint from , > specify the URL, IP address or the hostname of an HTTPS server to > provide a constraint. > Should the hostname resolve to multiple IP addresses, >
man ntpd.conf: small errors in constraints section
Some small issues in the new section: - 'NTP servers' means actual servers, not the keyword, so remove the .Ic - 'constraint' is used instead of 'constraint from' in some places; that might be ok as an abbreviation, but at least the example should use the full keyword. In the diff below, I used 'constraint from' everywhere. Index: usr.sbin/ntpd/ntpd.conf.5 === RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v retrieving revision 1.27 diff -u -p -r1.27 ntpd.conf.5 --- usr.sbin/ntpd/ntpd.conf.5 10 Feb 2015 19:21:16 -0000 1.27 +++ usr.sbin/ntpd/ntpd.conf.5 14 Feb 2015 15:55:54 - @@ -188,24 +188,23 @@ thereby reducing the impact of unauthent attacks. Received NTP packets with time information falling outside of a range near the constraint will be discarded and such NTP -.Ic servers -will be marked as invalid. +servers will be marked as invalid. .Bl -tag -width Ds .It Ic constraint from Ar url Specify the URL, IP address or the hostname of an HTTPS server to provide a constraint. If multiple -.Ic constraint +.Ic constraint from keywords are used, .Xr ntpd 8 will calculate a median constraint from all the servers specified. .Bd -literal -offset indent server ntp.example.org -constraint www.example.com +constraint from www.example.com .Ed .It Ic constraints from Ar url As with -.Ic constraint , +.Ic constraint from , specify the URL, IP address or the hostname of an HTTPS server to provide a constraint. Should the hostname resolve to multiple IP addresses,
Re: Default servers pool in ntpd.conf
On Wed, Jul 22, 2009 at 1:49 PM, Martin Schrvder wrote: > 2009/7/22 Ted Unangst : >> "Open source projects >> >> Open Source projects are of course particularly welcome to use the >> pool in their default setup" > ", but we ask that you get a vendor zone when using the pool as a default" > > But Theo has spoken. "they obviously don't mean that if it's taken them 15 months to not answer."
Re: Default servers pool in ntpd.conf
2009/7/22 Ted Unangst : > "Open source projects > > Open Source projects are of course particularly welcome to use the > pool in their default setup" ", but we ask that you get a vendor zone when using the pool as a default" But Theo has spoken. Best Martin
Re: Default servers pool in ntpd.conf
On Wed, Jul 22, 2009 at 01:07:42PM -0400, Ted Unangst wrote: > On Wed, Jul 22, 2009 at 12:36 PM, Jean Rebiffe wrote: > > To OpenNTPD developers, > > > > You use pool.ntp.org in the default configuration of the OpenNTPD > > daemon since 2004, but that is not compliant with the web page of > > the pool.ntp.org project designated to software vendors and operating > > system vendors, http://www.pool.ntp.org/en/vendors.html : > > "Open source projects > > Open Source projects are of course particularly welcome to use the > pool in their default setup" > > OpenBSD is an open source project. > Until I see the RMS Seal of Approval(tm) on the box, it's staying on the shelf.
Re: Default servers pool in ntpd.conf
We don't intend to change anything.
Their decrees are meaningless. They don't provide the ntp traffic,
they only provide DNS records. As written, those rules are designed
to let the people at ntp.org impose a punishing policy against those
they don't like.
Those rules do not improve time distribution. It is just control
freak behaviour.
> To OpenNTPD developers,
>
> You use pool.ntp.org in the default configuration of the OpenNTPD
> daemon since 2004, but that is not compliant with the web page of
> the pool.ntp.org project designated to software vendors and operating
> system vendors, http://www.pool.ntp.org/en/vendors.html :
>
> > You must absolutely not use the default pool.ntp.org zone names as
> > the default configuration in your application or appliance.
>
> > You can choose either to implement a full ntpd server or a simpler
> > SNTP implementation. A few more pointers and ground-rules:
> > * Only use the pool.ntp.org hostnames designated to you
> > (typically {0,1,2,3}.{vendor}.pool.ntp.org)
>
> > Open Source projects are of course particularly welcome to use the
> > pool in their default setup, but we ask that you get a vendor zone
> > when using the pool as a default configuration.
>
>
> In addition, the URL you use in comment corresponds to the public
> support services website of the NTP Project which "produces a reference
> implementation of the NTP protocol" and not to the pool.ntp.org
> project which maintain the DNS records used by softwares, OpenNTPD,
> the NTP Project's daemon, and others.
> The main page of www.pool.ntp.org (or maybe the "How do I use the
> pool.ntp.org?") seems to be more helpful to users to understand the NTP
> pool and to configure continental zone or country zone in their daemon.
>
> Regards,
>
> --
> Jean Rebiffe
Re: Default servers pool in ntpd.conf
On Wed, Jul 22, 2009 at 10:36 AM, Jean Rebiffe wrote: > > Open Source projects are of course particularly welcome to use the > > pool in their default setup, but we ask that you get a vendor zone > > when using the pool as a default configuration. they obviously don't mean that if it's taken them 15 months to not answer. -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: Default servers pool in ntpd.conf
On Wed, Jul 22, 2009 at 12:36 PM, Jean Rebiffe wrote: > To OpenNTPD developers, > > You use pool.ntp.org in the default configuration of the OpenNTPD > daemon since 2004, but that is not compliant with the web page of > the pool.ntp.org project designated to software vendors and operating > system vendors, http://www.pool.ntp.org/en/vendors.html : "Open source projects Open Source projects are of course particularly welcome to use the pool in their default setup" OpenBSD is an open source project.
Default servers pool in ntpd.conf
To OpenNTPD developers,
You use pool.ntp.org in the default configuration of the OpenNTPD
daemon since 2004, but that is not compliant with the web page of
the pool.ntp.org project designated to software vendors and operating
system vendors, http://www.pool.ntp.org/en/vendors.html :
> You must absolutely not use the default pool.ntp.org zone names as
> the default configuration in your application or appliance.
> You can choose either to implement a full ntpd server or a simpler
> SNTP implementation. A few more pointers and ground-rules:
> * Only use the pool.ntp.org hostnames designated to you
> (typically {0,1,2,3}.{vendor}.pool.ntp.org)
> Open Source projects are of course particularly welcome to use the
> pool in their default setup, but we ask that you get a vendor zone
> when using the pool as a default configuration.
In addition, the URL you use in comment corresponds to the public
support services website of the NTP Project which "produces a reference
implementation of the NTP protocol" and not to the pool.ntp.org
project which maintain the DNS records used by softwares, OpenNTPD,
the NTP Project's daemon, and others.
The main page of www.pool.ntp.org (or maybe the "How do I use the
pool.ntp.org?") seems to be more helpful to users to understand the NTP
pool and to configure continental zone or country zone in their daemon.
Regards,
--
Jean Rebiffe
