Hal Murray :
> Interesting, but...
>
> Why isn't refclock_gpsd a good example?
The protocol isn't bad. The implementation is kludgy and shoddy enough
to make me want to raze it to the ground and start over. Maybe I
ought to do exactly that...
> Is there a good package for working with JSON?
No
Where should we put the file used to store the key used to make cookies? It
gets read at startup and updated daily.
Fedora and Debian put things like that in /var/lib/ntp/
NetBSD and FreeBSD put them in /var/db/ntp/
There used to be a man/web page with a list of the default file names. I
ca
Interesting, but...
Why isn't refclock_gpsd a good example?
Is there a good package for working with JSON?
I'm not convinced that NTP is a good example. Sure, in hindsight, we can see
some problems, but it's not obvious to me that JSON is the answer. Are there
any interesting alternatives?
Achim said:
> In a nutshell, SIGHUP is already taken, but USR1 and USR2 are still
> available. Thte idea is that one of these does the equivalent of
> re-configuring via ntpq or a restart without loss of internal state (as far
> as possible).
USR1 and USR2 are already used to bump the debug le
James Browning said:
> It would pave the way to be rid of the symmetric signing mess though.
What symmetric signing mess?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/dev
Yo Ian!
On Wed, 6 Mar 2019 13:16:28 -0600
Ian Bruene via devel wrote:
> On 3/6/19 1:01 PM, Richard Laager via devel wrote:
> > On 3/6/19 12:19 PM, Achim Gratz via devel wrote:
> >> SNMP is as dead as a Dodo if you ask me…
> > It's used all over the place if you ask me.
>
> Common, dead, z
On 3/6/19 1:01 PM, Richard Laager via devel wrote:
On 3/6/19 12:19 PM, Achim Gratz via devel wrote:
SNMP is as dead as a Dodo if you ask me…
It's used all over the place if you ask me.
Common, dead, zombified hordes, whatever. I'd prefer to not have to deal
with it where not necessary.
-
On 3/6/19 12:19 PM, Achim Gratz via devel wrote:
> SNMP is as dead as a Dodo if you ask me…
It's used all over the place if you ask me.
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
A different RFC, eventually. But I'm not in a rush. Let people managing
large scale deployments figure out what works for them and then standardize
around it later.
On Wed, Mar 6, 2019, 13:25 Achim Gratz via devel wrote:
> Daniel Franke via devel writes:
> > That's correct: ensuring interop betw
Daniel Franke via devel writes:
> That's correct: ensuring interop between differing implementations of the
> NTS-KE server and the NTP server is outside the scope of this document.
So what are the plans for that department? Have everything bloom into
chaos or put it into a different RFC?
Regar
On Wed, Mar 6, 2019, 10:15 AM Achim Gratz via devel
wrote:
> In a nutshell, SIGHUP is already taken, but USR1 and USR2 are still
> available. Thte idea is that one of these does the equivalent of
> re-configuring via ntpq or a restart without loss of internal state (as
> far as possible).
>
USR
Hal Murray via devel writes:
> Eric said:
>>> I don't want the UI side of HTTP in ntpd.
>> I'd like to understand better what you mean by "the UI side" and
>> what your objection is.
>
> Web stuff is complicated. We'll get into UI wars.
> You can't easily script things.
Huh? HTTP is a transport
Eric S. Raymond via devel writes:
> This is so obviously the right thing that I'd like you to start an RFE
> on the tracker about it. I'll treat implementation of that feature
> as a prerequisite for removing ntpq :config.
This is my periodic reminder that your tracker requires setting up an
acco
On Wed, Mar 6, 2019, 03:33 Hal Murray wrote:
>
> dfoxfra...@gmail.com said:
> > The intended design for running NTS with pool servers is that only the
> pool
> > operator runs an NTS-KE server. The NTS-KE server then picks an
> NTS-enabled
> > NTP server out of the pool and serves you an appropri
dfoxfra...@gmail.com said:
> The intended design for running NTS with pool servers is that only the pool
> operator runs an NTS-KE server. The NTS-KE server then picks an NTS-enabled
> NTP server out of the pool and serves you an appropriate NTPv4 Server
> Negotiation Record. Individual server op
15 matches
Mail list logo
