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

[Hal Murray]

Big picture, only half thought out...

Please consider breaking this into several modular chunks.  The idea is that 
the chunks might be useful on their own and/or referenced by other HOWTOs.  
The examples that come to mind are setting up a similar system to use a 
GR-701W and how to find the IP Address of your new Pi.

The security section would obviously be generally useful.  It's worth 
mentioning firewalls and/or NAT boxes.  I think there should be a warning 
about plugging in a Pi that isn't protected one way or the other.

------------

You should probably mention that this description doesn't need a keyboard and 
display - if all goes right.  Another good separate document.

------------

>> I think it needs an introductory paragraph with a date-stamp
>> explaining that the PI-3 is new and still under active development
>> and don't be surprised if/when things break.

> I'm not really happy about the fact that we're presently stuck with one
> image - I'd rather we solved the UART-mode problem - but one side effect is
> that we presently dodge a lot of that kernel-level instability.  Yes, we
> apt-get upgrade, but the risks associated with that are decoupled from the
> moving-target nature of the 3. 

The point I was trying to make is that if you had published this a few weeks 
ago, then somebody following your directions would have been horribly 
confused with the new bugs.

I have no reason to believe that this current mess is the last Pi 3 bug of 
that will hit us.

[Battery on SKU]
> You're quite right about what it says, but that's a documentation error.
> There's a different reference that describes it as a supercap ...

Thanks.

[DogBone case]
> I'm not a fan. It makes sense for a multi-SBC stack that you might want to
> sit in front of a fan, but for a single SBC/HAT pair it seems more like an
> aesthetic statement than practical protection.  (The threat model for my
> setup has to include curious-cat paws.) 

It seems worth mentioning.  It might be interesting for people who don't have 
a Dremel.


>>> We provide a script, ddimage, to semi-automate
>> I think you need a few more words here.
> Along what lines? That is, what could I say that's not conveyed by the
> example session? 

You started describing and running ddimage without describing where it comes 
from and/or how to get it.


> Added: "Another possibility is that your host doesn't have a zeroconf
> implementation like Linux's 'avahi-daemon' installed.  Try to fix that.  If
> you can't, your host setup is outside the scope of what this HOWTO can
> handle; get expert help." 

Another example where a separate document would fit in well.


>> If that gets a new kernel, you want to reboot.
> clockmaker normally calls reboot at the end of the --config phase, anyway. 

If you are describing the internals of clockmaker, you should include the 
reboot step.

[finding north]
> This is an invariant of the HAT specification.
Ahh.  That's a cutout for a ribbon cable to the display.  It would probably 
help to mention that.

>> 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? 

You have to wire the breakout board to the P1 pins.  There is nothing like a 
PCB that constrains any of the connections.  Everybody agrees on which Rx and 
Tx pins to use.  (There are probably other UARTs that could be used, but they 
might overlap with the camera or display or ...)

The PPS can go to any of several pins.  The simple approach is to pick one 
from a HAT table and follow the directions for that HAT.  There are probably 
others that can be used.

[Using "good" 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. 

Another message...


> That's deliberate avoidance of complications I don't want to have to try to
> explain at this point.  It belongs in a section under "Advanced Topics" and
> I don't have a clue how to write it - my outside-in view is still deficient
> there.  I'd take a patch. 

Another example where a modular structure would work well.

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

Then please add a few words about where it comes from and such.  Maybe 
clockmaker needs an introductory section that explains what it will do and/or 
lists all the files it will create and what they do.

>>> Install this text as the file /etc/init.d/timeservice and make it 
executable:
>> How do you expect "this text" to magically turn into a file?
> I do note that I expect the uset to be able to use a text editor.  In fact,
> clockmaker --install does this; thus, I expect by hand installs to be unusual
> and confined to people who know whatbthey're doing.

I found that section hard to read, much harder that the rest of the document. 
 Maybe "this text" should be "the following block of text".

[security first]
> 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. 

If we are calling the project NTPsec, we should pay serious attention to the 
sec part.


>> The recipe for removing WiFi would be convenient.  Or a pointer to one.
> I don't actually know it.

>From my notes:

Nuke Bluetooth and WiFi:
  https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=138610
  blacklist the modules
  Edit /etc/modprobe.d/raspi-blacklist.conf, insert:
#wifi
blacklist brcmfmac
blacklist brcmutil
#bt
blacklist btbcm
blacklist hci_uart



-- 
These are my opinions.  I hate spam.