For the past few years I have found the versatility and robustness of Raspberry Pi’s to be a great experience to work with. Sure I could exude the low power and open source virtues, but in reality the Raspberry Pi is great for its simplicity; barebones linux hardware that has a serial out. Sure the things are not going to win any awards for performance or design, but when I have an idea for a project the ability to have code running in a matter of minutes on a dedicated system is amazing!
Here are some examples past projects:
The core reason for using the Raspberry Pi boils down to the basic requirements of reliability, ease of interface, and extensibility. The reliability of a Raspberry Pi is impeccable; I have taken the same Pi to the desert multiple times where it operated for a week at a time with no problems (the SD card is more likely to fail so make sure you try and “seal” the connector and the card with painters tape). The ease of interfacing with a Raspberry Pi for pretty much any project is well documented, as part of the culture of the hardware. For almost every idea I can come up with, someone has already done a writeup or at least enquired whether something would be possible, which makes exploring ideas much more fluid. I am sure there are a host of other reasons why the Raspberry Pi is a good choice for exploring capabilities, developing ideas, and iterating fast!
Implementation Details Drive the OS
Based on what I am doing I will either use the default Raspberry OS which used to be Raspbian or Ubuntu Mate which feels a lot more like a typical Linux distro, but has its own limitations of certain packages not being available for an Arm chipset.
Daily reboots
The easiest way to keep these machines running smoothly is to reboot them often. While it used to be a badge of courage to know how long a machine can stay running before needing to be rebooted, I realize that keeping something operational is much more impressive. The easiest way to ensure this is to schedule a nightly reboot when users are sleeping using Crontab.
# this is to set the cron job on the root user, which is required
sudo crontab -u root -e
# add this line to the crontab file
0 4 * * * reboot
SSH access
For Raspian
Create the SSH file: https://www.raspberrypi.org/documentation/remote-access/ssh/ For headless setup, SSH can be enabled by placing a file named ssh, without any extension, onto the boot partition of the SD card from another computer. When the Pi boots, it looks for the ssh file. If it is found, SSH is enabled and the file is deleted. The content of the file does not matter; it could contain text, or nothing at all.
For Ubuntu Mate
# try this first
sudo systemctl enable ssh
sudo reboot
# if that does not work then go nuclear
sudo apt-get remove openssh-server
sudo apt-get install openssh-server
sudo systemctl enable ssh
sudo reboot
Setup Wireless
Setup the wpa_supplicant files to enable the wireless network to connect automatically. This is the easiest approach to manage a headless device.
Give everyone r/w access to the conf file so you can append to it
sudo chmod 666 /etc/wpa_supplicant/wpa_supplicant.conf
Now append the wireless info to the conf file
sudo wpa_passphrase myPSID myPassword >>/etc/wpa_supplicant/wpa_supplicant.conf
Verify the wireless network information supplied is present
cat /etc/wpa_supplicant/wpa_supplicant.conf
Revoke access to everyone
sudo chmod 600 /etc/wpa_supplicant/wpa_supplicant.conf
Project Auto Pulling
This is not what I would call a best practice, but when you have a small development platform it is sometimes easier to set a crontab to git pull from the projects repo every 5 minutes or by adding a script to /etc/network/if-up.d to run on connection to a wifi network that pulls the latest on the device. This is not ideal, first it requires the startup script to include the build process which adds complexity and introduces dependency issues. Second, Docker is the proper tooling for the job if traceability and reproducibility are important then that Docker image is better to have laying around.
Reverse Proxy
I have only set one of these up while trying to tie together a public/private cloud. This allows for the Raspberry Pi to be exposed to the outside world, which may not be the best thing for security but allows you to test and DMZ the network’s VPC.
PiHole
The hands down best feature that has been deployed and made common amongst nerd households is PiHole, which handles DNS requests. By blocking ads and ad networks on the DNS level it makes the load of blocking them in the browser a lot lower.
Conclusion
The Raspberry Pi is not the best server, but is great for a service. This seems to be inline with the industry standards of microservices.