Draft Stratum 1 Microserver HOWTO is up

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 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.

An appealing idea in the abstract, but not going to happen soon.  I have
other tasks to do - I need to wrap this up, get it shipped, and tackle
the TESTFRAME problem again (through Mozilla rr or another simpification
attack on the hairball).

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

Agreed.  Added:

    Now check your security.  You need to be behind a NAT box or firewall
    for the next several steps.  If anyone on the public Internet can
    reach your SBC via ssh before you remove the default account, your Pi
    could be enslaved by an attack bot within minutes.

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

Done.

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

No doubt you're right, but I don't think that sort of bug will hit us
until we change kernels - that is, unpin the image we're using. I'll
add such a warning then.

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

Already fixed, I think:

    Better yet, we provide a script, link:ddimage[ddimage], to
    semi-automate the next step of the process; it's safer to use that,
    because it performs some sanity checks that should prevent you from
    scribbling on your disks. If you used clockmaker --build, ddimage will
    have been downloaded to the directory where that script was run.

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

Yes, but I can't do it.  I can't justify spending the time it would require.

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

Didn't I just do that?

> [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.

Done.

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

Got it.  Paragraph removed.

> >> > # 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.

It already has one.  I'll add the file list.

> >>> 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".

Shall do.

> [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.

See my reply to Gary and your text about NATs and firewalls.  Nobody has
convinced me that this procedure *isn't* taking security seriously, nor
will they until I understand how any machine other than the one I port-forward
to is visible to outsiders.

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

Is there any reasin this ids better than apt-get remove wpasupplicant?

I believe what we already do disables Bluetooth.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>