anthturner
commented
7 years ago We're doing pretty well here. I need to document the installer more formally but the current process kind of goes something like this:
- Write an image with PiBakery that on first boot runs /boot/bootstrapper.sh (I don't know whether PiBakery deploys its entire on-boot script infrastructure if you leave the project blank, but if so, just using the tool at all is all we need; we overwrite their stuff anyways)
- Overwrite (FAT32)/PiBakery/firstBoot.sh with our own file that invokes /boot/bootstrapper.sh (file must be saved with UNIX line endings!) -- we need this because their script won't show our script's output, so it'll look like it's hung for a half hour while all the builds run
- Optionally put ybts.conf and/or sar.conf in (FAT32)/sar_overlay (will be used as the initial config, otherwise the sample configs are copied into the root of the drive to be modified by the user before first use)
- Optionally create preinstall.sh and postinstall.sh in (FAT32)/sar_overlay -- for our development, this chmods/chowns the SSH keys 600/root in pre, and turns off DHCP and sets the IP to 192.168.88.248 in post
- Optionally put files to be copied into the Linux filesystem in (FAT32)/sar_overlay/skel -- for our development, we put SSH keys in (FAT32)/sar_overlay/skel/root/.ssh for the private repository
After this is done, plug the Pi into a monitor (no keyboard required) and an internet connection, and boot. We clone the HEAD of this git repository and run the installer.sh script out of the devops folder. The bootstrapper script is also in the devops folder (and the Git URL can be changed if people fork this in the future).
If I have a new SD card and Raspberry Pi, how can I get it running our code in a reproducible way from this repository?
Probably includes