Yo Hal!
On Thu, 07 Mar 2019 13:17:25 -0800
Hal Murray via devel wrote:
> Gary said:
> >> Or, we could fix SHM so the client side is read-only.
> > As Eric has said: Changing the SHM protocol is not an option.
>
> I believe there is a reasonable way to do it.
>
> GPSD writes to both old an
Gary said:
>> Or, we could fix SHM so the client side is read-only.
> As Eric has said: Changing the SHM protocol is not an option.
I believe there is a reasonable way to do it.
GPSD writes to both old and new forms.
ntpd supports two drivers (or a mode bit)
If you want to add SHM via HUPing
Yo Hal!
On Thu, 07 Mar 2019 12:25:52 -0800
Hal Murray via devel wrote:
> Gary said:
> >> What would ntpd need root for?
> > SHM(0) and SHM(1).
>
> That would mean that you would have to restart ntpd to add SHM
> drivers.
>
> Or, we could fix SHM so the client side is read-only.
As Eric ha
Gary said:
>> What would ntpd need root for?
> SHM(0) and SHM(1).
That would mean that you would have to restart ntpd to add SHM drivers.
Or, we could fix SHM so the client side is read-only.
The comments in ntpd.c
#ifdef ENABLE_EARLY_DROPROOT
/* drop root privileges */
/* This
Yo Hal!
On Thu, 07 Mar 2019 11:49:21 -0800
Hal Murray via devel wrote:
> What would ntpd need root for?
SHM(0) and SHM(1).
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@re
> One problem that just occured to me is that any actual restart will have to
> be done with dropped privileges already. The PID shouldn't change during
> restart anyway, so maybe that's taken care of already.
Currently, one of the privs it drops is being able to change privs so there is
no w
Hal Murray via devel writes:
> 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 a
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
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
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 3/5/19 1:26 PM, Gary E. Miller via devel wrote:
>> and by what
>> mechanism (i.e. are you using the Mode 6 writable parameter(s) being
>> proposed for removal)?
>
> I do it with: killall ntpd
The mode 6 changes aren't really relevant to you then. I see the
security (and complexity) benefit to
> Maybe this isn't a good path to go down after all.
This has been requested for a long time. I think it's worth the effort. We
just have to find the right person (team?) and the right time.
It may involve cleaning up that area, but that's not bad. Or maybe just
rearranging, or maybe just a
Hal Murray via devel :
> The config file touches a lot of stuff. You basically have to diff the old
> and new config file. Removing a server is simple. Adding a new server is
> simple. Removing a tinker operation requires knowing what the default
> is/was.
> That's probably another slot in
Gary said:
> But I would like something like SIGHUP to get ntpd to re-read the config file
> and yet keep state.
I think something like that is possible. It's not simple, but not horrible.
The HUP logic is there. It works for a new leap file and new log file when it
gets rotated.
The confi
On Tue, Mar 05, 2019 at 12:46:29PM -0600, Richard Laager via devel wrote:
> On 3/5/19 12:45 PM, Gary E. Miller via devel wrote:
> > Yo Eric!
> >
> > On Tue, 5 Mar 2019 02:11:52 -0500
> > "Eric S. Raymond via devel" wrote:
> >
> >>> That would leave the configure option. I've never used it.
>
Achim Gratz via devel :
> > You want to reconfure your ntpd? Bounce it. This won't happen often.
>
> Depends. While you're trying to figure out the correct fudge times for
> instance you need a fully converged ntpd to see what's going on. If I
> have to restart ntpd each time I want to adjust t
Yo Richard!
On Tue, 5 Mar 2019 12:46:29 -0600
Richard Laager via devel wrote:
> On 3/5/19 12:45 PM, Gary E. Miller via devel wrote:
> > Yo Eric!
> >
> > On Tue, 5 Mar 2019 02:11:52 -0500
> > "Eric S. Raymond via devel" wrote:
> >
> >>> That would leave the configure option. I've never used
On 3/5/19 12:45 PM, Gary E. Miller via devel wrote:
> Yo Eric!
>
> On Tue, 5 Mar 2019 02:11:52 -0500
> "Eric S. Raymond via devel" wrote:
>
>>> That would leave the configure option. I've never used it.
>>
>> I think we can justify both removals on security. If Mode 6 is a
>> read-only channe
Yo Eric!
On Tue, 5 Mar 2019 02:11:52 -0500
"Eric S. Raymond via devel" wrote:
> > That would leave the configure option. I've never used it.
>
> I think we can justify both removals on security. If Mode 6 is a
> read-only channel there can never be any exploits over it. That's
> a significa
Eric S. Raymond via devel writes:
>> That would leave the configure option. I've never used it.
I did. It's one of the few ways you can change (some) things around
without haveing to re-start ntpd, with all the chaff that produces.
> I think we can justify both removals on security. If Mode 6 i
> There is one interesting area that it doesn't cover. The kernel (on most
> OSes) has an optional PLL that locks on to a PPS source. ntpd acts as a
> sanity check and turns that on and off. If we want to use that mode, we need
> a back channel, or an ugly wart in ntpd. We can probably get t
Hal Murray :
>
> e...@thyrsus.com said:
> >> Do you have an example of where we need to change a
> >> driver variable on the fly?
>
> > No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
> > pretty sure what the Dread God Finagle will arrange if I assume we won't.
> > :
e...@thyrsus.com said:
>> Do you have an example of where we need to change a
>> driver variable on the fly?
> No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
> pretty sure what the Dread God Finagle will arrange if I assume we won't. :-)
I just looked at the code.
Hal Murray :
> Do you have an example of where we need to change a driver variable on the
> fly?
No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
pretty sure what the Dread God Finagle will arrange if I assume we won't. :-)
> >> We need to be able to run gpsmon while
e...@thyrsus.com said:
> The two most obvious pain points here are the fudgetime variables. Some
> refclocks set their own custom clock variables, as well; the generic driver
> in particular, I think one other as well.
The fudgetime variables can remain in ntpd.
If the problem is the driver se
Hal Murray :
>
> Eric said:
> >> I don't understand. All I was trying to say is that splitting
> >> out the refclock drivers to another process shouldn't make
> >> any difference that is easily visible.
>
> > Maybe. The devil is in the details.
> > I expect some issues around Mode 6. We'd still
Eric said:
>> I don't understand. All I was trying to say is that splitting
>> out the refclock drivers to another process shouldn't make
>> any difference that is easily visible.
> Maybe. The devil is in the details.
> I expect some issues around Mode 6. We'd still need to exchange control
>
Hal Murray :
>
> e...@thyrsus.com said:
> >> My strawman for REFCLOCKD is something like the touring test.
> >> You can't tell the difference by poking around with ntpq. (Maybe
> >> you don't get to poke too deep.)
>
> > It'd need its own UDP port.
>
> I don't understand. All I was trying to
e...@thyrsus.com said:
>> My strawman for REFCLOCKD is something like the touring test.
>> You can't tell the difference by poking around with ntpq. (Maybe
>> you don't get to poke too deep.)
> It'd need its own UDP port.
I don't understand. All I was trying to say is that splitting out the
Hal Murray :
>
> My strawman for REFCLOCKD is something like the touring test. You can't tell
> the difference by poking around with ntpq. (Maybe you don't get to poke too
> deep.)
It'd need its own UDP port.
> There are two parts to the refclock code.
>
> The first operates on the second t
My strawman for REFCLOCKD is something like the touring test. You can't tell
the difference by poking around with ntpq. (Maybe you don't get to poke too
deep.)
There are two parts to the refclock code.
The first operates on the second time scale. The main thread calls the
refclock receive
Hal Murray :
>
> Eric said:
> > I meant to mention that there are actually *two* big benefits in prospect
> > from a Go port. The obvious one is being able to junk a lot of fiddly,
> > error-prone C memory-management stuff.
>
> I'm actually surprised that you haven't simplified a lot of that ye
Eric said:
> I meant to mention that there are actually *two* big benefits in prospect
> from a Go port. The obvious one is being able to junk a lot of fiddly,
> error-prone C memory-management stuff.
I'm actually surprised that you haven't simplified a lot of that yet.
There are several plac
Ian Bruene via devel :
> On 3/2/19 9:42 AM, Eric S. Raymond via devel wrote:
> > REFCLOCKD benefits way down, cost almost unchanged. Every time I model
> > this in my head the same answer comes out: bad idea. I think we have
> > better complexity-reduction attacks available, like translating the
>
On 3/2/19 9:42 AM, Eric S. Raymond via devel wrote:
REFCLOCKD benefits way down, cost almost unchanged. Every time I model
this in my head the same answer comes out: bad idea. I think we have
better complexity-reduction attacks available, like translating the
whole thing to Go to get rid of a
This is redirected from a bug thread on issue #563.
Hal Murray :
>
> Eric said:
> > Sadly, I think the great refclock cleanup is mostly done. There are issues
> > about the GPSD and SHM drivers but the days when I could dike out an
> > obsolete
> > driver a week are gone - we seem to be down to
37 matches
Mail list logo
