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

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> Great progress, but...
> 
> It could use some photos, got a smart phone with camera?

There is now one photo, of the blue-wire mod required for the Chinese
board. What others would you suggest?

> "a HAT uses an internal RS-232 interface "
> 
> ±5v to ±15V?  I think not, and not so 'internal'.  I'd say:
> 
> "a HAT uses an direct serial interface "

Done.

> Typo:
> 
> "Uputronics board snugs ino an on-board fitting and"
> 
> ino -> into

Already fixed.

> "A bit of work with a dremel will fix that. "
> 
> Dremel(tm)

Done.  But I was under the impression the trademark had genericized.

> "Note: your host may automount the card if it has been set up for Linux before. You should unmount it."
> 
> Uh, how?
> 
> I use "dmesg | tail" to check, you don't like that.  Do we tell the user about
> df or mount?
>
> I know Ubunut does automount, and it does so in a weird and barely predictable
> manner.

It looks unpredictable because it's actually a function of the WM you're using.
The one I use, i3, never automounts. Others exchange go/no-go information with
automountd in ways which (a) I don't understand, and (b) may be buggy.

Fortunately, we can evade that whole level of complication by noticing
that automount, when it happens, isn't quiet.  Thus I get around the
CLI problem with this text:

    Note: your host may automount the card if it has been set up for
    Linux before - whether this happens depends on what distribution
    and desktop environment you are using. If your window manger pops
    up a file-browser view of the device, you should unmount it
    through that GUI.

> ". On a host running Debian or Ubuntu, the device will likely be /dev/sdd and your command will look something like:"
> 
> Whoa Nelly! telling the user to dd to a device they have not triple
> checked is the right one!  Gack.

That's why the text recommends ddimage, which has sanity checks out the wazoo.
The recommendation is stronger now than it was in the version you were
responding to.

> "# ddimage sdd"
> 
> For upard compatibilty, maybe change the script to take the image file name?
> Maybe even do the unzip to?
> 
> So, instead of:
> 
> # unzip 2016-03-18-raspbian-jessie-lite.zip
> # ddimage sdd
> 
> Just:
> 
> # ddimage sdd 2016-03-18-raspbian-jessie-lite.zip

Good idea. Done.

> ddimage could unzip to stdout and save some disk space:
> 
> unzip -c 2016-03-18-raspbian-jessie-lite.zip | ddfldd bs=4M  of=/dev/sdd

Disk space is cheap. Waiting is expensive.  I'd ratther conditionally
unzip if the img file isn't already present.

> I would copnsider adding "sync" to the end of the script so it does
> not complete before the iamge is fully on the sd card.  otherwise
> the user might remove the card after the script completes, but before
> the card is fully written.

Excellent idea.  Done.

> "Make sure your Pi has a live Ethernet cable plugged in and "
> 
> The network leds should flash.  Then try the ssh...

Added: "(or, if you can see the Ethernet-port LEDs, wait for them to
start flashing)"

> Typo in the clockmaker script:
> 
> # that the --nstall mode will install.

Fixed.

> "These changes are not reversible, but you’d want them for any other
> use of the SBC anyway."
> 
> How about:
> 
> "These changes are not reversible, but you always want to be updated
> with security and other updates."

Added.

> " but not before installing some packages need for the next step."
> 
> need -> needed

Fixed.

> Table 1. Blink interval in seconds
> 
> Same blink SKU 424254 for fix and not fix???

Sadly, yes.

> "take 20-30 minutes to download a satellite ephemeris. "
> 
> ephemeris -> almanac

Done.

> "You should see NMEA0183 sentences issuing in bursts once per second"
> 
> example?

I didn't try because you can't really convey the burst timing in print.

> "server 127.127.28.0
> fudge 127.127.28.0 refid GPS"
> 
> maybe start with a 420 mS fudge?
> 
> So:
> 
> server 127.127.28.0
> fudge 127.127.28.0 time1 0.420 refid GPS

I don't want to wire in assumptions about the GPS type here,
especially since we're supporting three different types. There should
be an Advanced Topics section - not yet written - about computing a
fudge.  Or, if you think the discussion in the GPSD Time Service HOWTO
is complete enough, we can just point at that.

> "Turn off the default ntpd service running on your SBC"
> 
> Maybe just uninstall the POS?

That's in the config --install stage.  Remember, one goal of this
procedure is minimizing reversibility effort until we know the
software works.

> Gack, you forgopt the -n!!!
> 
> # gpsd/gpsd /dev/gpsd0

I did not.  It's forced in the timeserver build.

> "Install the pinup script:"
> 
> Uh, I don't have that??

You do.  clocmaker --build copies it in.  If it doesn't, update your copy.

> " If you decide to ditch systemd you can mame a link"
> 
> mame a link?  Ouch!

Already done.

> "and use ntpq -p to verify that you can see time samples coming in."
> 
> How about "watch ntpq -p" ?

Done.

> "On the SBC, create an account for "me" (whatever username you like)
> using adduser run as root."
> 
> I have seen windows hosts hacked in minutes after going live.  Do this
> WAY earlier in the process.

I think this is over-paranoid.  Your Pi is not an Internet-facing machine;
for it to be cracked, bad guys would already have to have subverted a
host on your LAN.  If that's so, nothing they do to your Pi is likely
to make matters much worse than they already are.

Again, the reason I moved this to late in the sequence is to minimize
user hand-work before the point where we know the build would work.
I consider that important.

> Duplication!
> 
> "You will probably want to re-fetch clockmaker and do a "clockmaker --build" in your home directory."
> 
> Another reason to add the new account early.

This may be a reason to restore the old sequence. I'm still thinking.

> "Don’t be overly concerned if ntpq -p initially shows large jitter. "
> 
> Examples of good and bad?

Please supply and explain them. I'm still not sure of my ability to
tell the difference.

> "The resulting configuration is pretty minimal, as you can verify by running "ps ax" 
> 
> I find perple get "pstree -paul" a lot quicker.

Good point.  Now says "as you can verify by running "pstree -paul" (or
the older-school "ps ax")"

> "The important thing to check is whether the pps-gpio driver triggers on
> leading or trailing edge."
> 
> 
> Uh, no.  Always the leading edge, but is the leading edge the assert
> (rising) or clear (falling) edge?
> 
> leading -> assert (rising)
> trailing -> falling
> 
> The adafruit HAT has the leading edge on the assert edge.
> Other GPS can have the leading edge on the falling edge...

Done.

> " as your Odroid will be running a stock Ubuntu rather than Raspbian. "
> 
> Mostly stock Ubuntu.  I found that out the hard way.  It is a custom
> kernel.

Amended.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160524/40c27be4/attachment.bin>