Re: [gpsd-dev] PPS and privilege-dropping

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> Well, for me, it is broken.  It does not build for me and there are
> newly introduced bugs.

You have since reported it building.  One of us (I'm not sure who) deleted
a * in a comment ender.  I've fixed that.

> Please tell me you have KPPS in your system before touching KPPS code
> again.

I've had KPPS installed and working for about 24 hours now, and have
live-tested it successfully.

> > ship_pps_drift_message() in gpsd.c.
> 
> Ugh.  That is seriously broken in more than one way.  It explains
> some errors I have been seeing but had not tracked down.  Let's get PPS
> so it builds again and then I will fix that too.  How about you move
> that to ntpshm.c so it is obvious that it is a non-thread safe function
> in a thread. Then I'll make sure it is one reporting the right data and
> two doing it in a thread safe manner.

I specifically *don't* want to move that code from where it is, for
architectural-hygiene reasons.  Doing so would create a nasty cohesion
and drag a reporting helper tied to JSON emission into code where it
doesn't belong.

At present, only gpsd uses ntpshm.c, but it would be wrong to assume
that will always be the case.  In the future I might very well write a
dedicated time-drift monitor that would watch PPS without needing to
do any of gpsd's session management and socket-fu, and would never
ship JSON.

What should be thread-safed is not ship_pps_drift_message() itself, but the
call to the pps_hook slot in the context structure.  I created that so that
the PPS handler would have a way to call out to reporting code without having
to know or care exactly what it does.  We must preserve that property.

The content of the report is a different issue.  You have implied that the
data in it is misleading; I want to know why you think that and, if 
required, fix it.  (See "representation of domain" below.)

> > > > A brief tutorial on how to choose NTPd offset parameters would be
> > > > good to have in the HOWTO, too.  Basically I want this to be a
> > > > primer for the relatively ignorant - like, er, me.
> > > 
> > > One could argue that is out of our scope as it is in the ntp.conf
> > > file.  Basically you get several good chimers and adjust fudges
> > > until they all agree.  From what I can tel no one really does it
> > > right.
> > 
> > Nobody does it right because the few of you who know the black magic
> > have never documented it.  So let's *fix* that, dammit.
> 
> The problem is that it is all any time-nut needs and it has never been 
> clear what it is that a non-timenut does not get.

I understand that.  You're telling me that the documentation problem
is harder than usual here.  That's quite OK, I'm better at it than
most people! Not all of it is knowing how to write; an important part
is knowing how to elicit knowledge from domain experts like you who
are only half-aware or unaware of how their knowledge is organized.

This is what AI people call a "knowledge engineering" problem; we need
to figure out how a time-nut's representation of the domain is
different from a non-time-nut's and then capture that difference.  The
challenge goes beyond just enumerating specific technical facts
accessible to both kinds of people into extracting the conceptual
model or narrative that a time nut uses to organize those facts.

I freely admit that I don't get it.  I know a lot of specific isolated
things about time service, but they don't cohere for me into a whole
that would permit me to set up and tune a time server and then
diagnose problems.  Now I intend to get it, and in the process I
intend to capture and document the time-nut way of thinking about
those facts.

I'm tackling this because having all this remain deep black magic
grokked only by a handful of people is a *risk*, a kind of
infrastructure vulnerability.  I consider mitigating this kind of risk
to be nearly as important a part of my job as writing good code.
That's why I write and maintain so many how-to documents.

(I've been aware that I would eventually tackle the time service risk
for some time.)

I'm explaining this in detail in hopes of motivating you.  I want
you to understand that the privacy of your knowledge is a risk,
a bug, and needs to be fixed.

>                                              That is why I always
> welcome people new to something to say what the doc lacks.

That's not enough by itself.  You and other time nuts have implicit
knowledge, expressed in jargon like "chimers" which isn't actually
defined anywhere (I googled to check).  We need to get that knowledge
onto (virtual) paper.

> BTW, there was an article on this years ago in Linux Journal that was
> well written.  We should get a copy of that to look at.

Was it one of these?

http://linuxtoolkit.blogspot.com/2009/06/setting-up-ntp-server-for-local-network.html

http://www.linuxjournal.com/article/6812
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature