[gpsd-dev] Draft Stratum 1 Microserver HOWTO is up

[Gary E. Miller]

Yo Eric!

On Sat, 21 May 2016 10:53:51 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> > > device will likely be /dev/sdd  
> > 
> > Mine works out to be sdd, but I think that depends on several
> > things.  I have a second hard disk that gets sdb, and I use a
> > multi-slot USB to small-card adapter that sets up sdc, sdd, sde,
> > and sdf.  The SD slot just happens to be sdd.  
> 
> This is also what you'll get on a 2-disk system with sdc mapped to a
> DVD reader, which is a pretty normal configuration for a tower PC.  I
> think all we can do here is pick a "likely" target and note there is
> variability.

Given how disatrous doing a dd to the wrong device can be I'd like to
get a higher level of confidence than "likely".

I have sd cards show up all over, up to /dev/sdl, and sometimes beyond.

For example, when I plug in a SanDisk All-In-One USB reader it takes up
4 /dev/sd?, even with no cards plugged into it.

> (I'd worry more about this if ddimage didn't check for
> device-mountable-but-unmounted status.  That's the main reason I wrote
> it.)

Good, but good enough?  Especially since the HOWTO gives the bard
dd command.

Maybe have people do an 'fdisk -l' and verifying card size?

I'll own up to dd'ing the wrong device more than once, I doubt I am
the only one here to do so.

> > The breakout board doesn't know anything about GPIO pins.  You are
> > probably thinking of some writeup that cloned the Uputronics pins.  
> 
> I'm confused.  Are you telling me that the breakout board doesn't
> connect to the GPIO?

Not directly, you use jumper cables.

See this page:
	https://blog.adafruit.com/2016/04/22/absolutely-epic-howto-configure-raspberrypi-for-stratum-1-network-time-protocol-piday-raspberry_pi/

> > On top of all that, the connectivity is only good if you are
> > located near the servers.  
> 
> I understand you, and I want us to be good citizens, but reality
> seems to be backing us into a corner here.  Gary has strongly advised
> against using general pool servers. His reasons seem cogent,
> especially if our Pis are going to be used, as intended, to *feed*
> the pool. We don't want our Pis to create a GIGO loop that
> indiscriminately boosts the signal of crappy servers.

I think the pool servers are good enough for this howto.  At least if
you use country specific ones.  Maybe an appendix the howto could
describe how to pick better ones.

> I'd prefer not to use check servers at all and supply only the GPS
> time after sanity-filtering it locally.  But I've been too busy to
> follow up on the discussion of whether they're actually required (I
> badly want to, but my mailbox keeps getting flooded...)

It is good for the newbie to see how well his chimer works compared to
others.  The newbie can see it is pretty close to what others say is
the 'correct' time and seems more stable.

> Until that issue is resolved, I don't see that I have any alternative
> but to default to a fixed set of known-good servers that implicitly
> hold themselves forward as public utilities.  You going to tell me
> that a hostname like 'clock.isc.org' isn't doing that? :-)

Not for someone in China or France.

> > > # cp pinup /usr/local/bin  
> > What's "pinup"?  Where did it come from?  
> 
> clockmaker --build installs it.

Yes, but not documented as being from clockmaker and nnot from NTPsec.

Maybe it should be in NTPsec?

> > I think adduser needs a few flags.  I normally forget them and have
> > to go back and patch things up.  
> 
> The Linux versions prompt you for fields you don't specify.

Some do, some don't.  As long as the Raspbian does.  On Gentoo it does
not, you use superadduser for the friendly prompts.

> > I would reorder things so that happens naturally.  Just do the
> > security stuff first.  
> 
> I used to sequence it that way.  I changed it deliberately, not
> without hesitation.  I might change it back, and take your objection
> seriously towards that end.

I object.  I've seen too many people hacked before they get to the
part about changing their passwords.

> Two considerations cut the other way.  One is minimizing therbligs.  I
> elected to reduce the amount of handwork between start and the GPS/HAT
> smoke test as much as possible, in case it fails and the user has to
> restart.  If the basic system integration no workee, the security
> stuff is irritating waste motion.

Yes, but then you duplicate which account the srouce is installed in.

> The other is that securing the machine is a policy step, implictly
> optional.

NOOO!!!!!  Not optional!!!

> > Mumble.  That's long and complicated.  I would simplify things
> > greatly.  Drop the ppio detects column until we get an example that
> > is different.  
> 
> It's possible we already have one.  I expect to have access to a scope
> later today to cceck.

No need, just plug in a GR-601W and see if their PPS agree.  The usual
pulse width of 200 milliSec is readily obvious in ppstest when comparing
the HAT to the GR-601W.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160521/b4e1ebf3/attachment.bin>