For the past two years, I’ve had a hacked together system combining a desktop PC running Ubuntu headless and a Pogoplug v4 running Arch Linux ARM headless. The PC handled all download scheduling, Pihole, centralized media library database for 4 instances of Kodi, external SSH access, and for a brief time an instance of MythTV. The Pogoplug v4 handled the shared 10 TB of hard drives on the network over Samba, and formerly external SSH until a botched update broke SSH. Attempts to restore SSH access to the Pogoplug were temporarily successful, until updates once again borked it.
Now I’m rebuilding the setup under a single Raspberry Pi 3, for power consumption reasons and simply because I’m bored. Come along on the journey, while we explore if all of this functionality can be placed into an SBC (no MythTV is not being installed on the Pi 3, although previously that has occured). I’m mostly interested in how many simultaeneous HD streams it can serve up over the 100 Mbps ethernet that is shared with the USB 2.0 bus. I have no reason to beliew
The first step in any project like this is to choose the base operating system which will enable the Pi 3 to do all the necessary functions. On researching the options available, I had a choice to make. 0) I can do it the hard way, start with the most recent version of Raspbian, or 1) I could install a system that has some or all of the functionality built in and add on as required.
I went with option 1, because I was on a bit of a time constraint and really wanted to finish the process in under 4 hours.
As already discussed, Raspbian was out, because although it can be done, I really wanted to be lazy. The next option was OpenMediaVault. This would serve all of my file server need, and would only need to add on SabNZBD, Sonarr, CouchPotato, HeadPhones, and MySQL to complete the process. This seemed easy enough, but attempting to log in over ssh at the start was a hassle, and mono would need to be compiled for the processor. Since I don’t have a cross compiling environment configured, it was on to plan B.
Plan B was DietPi. I had never heard of this software prior to this grand experiment, but was willing to give it a chance. After all, the setup I have currently works, the worst that would happen is I keep the existing arrangement if it fails to function.
DietPi on first boot, seemed like a winning choice. I’m a big fan of running things headless, since that means I can sit in the comfy chair at my desk, and ssh into the device. DietPi does not launch a GUI on first boot, instead it displays the ip address, user name, and password, and leaves it to you to figure out that things should be configured over SSH.
Once I was able to log in over ssh, I logged out, and performed my favorite bash command “ssh-copy-id”. I really can’t stand having a SSH server accept password authentication, and this system would not fall into that trap. Besides, I have seen way too many attempts to try to brute force a password with a user name of “pi”. This is one of the favorites to attempt by people who practice the “throw it at the wall and see if it sticks” method of intrusion. No reconnaissance, just blast everything that has port 22 open to the world with a username of pi and password raspberry, and you are bound to get a shell somewhere. I can’t really fault them, it works because many people don’t change default passwords.
On logging in, the Diet-Pi configuration wizard loaded up with many options, and to my suprise, almost everything I needed was available. PiHole, Sonarr, SabNZBd, Deluge, NFS, and Samba servers. No standalone MySQL server (many choices for webserver stacks, but I didn’t want to be installing unnecessary packages) which will be rectified later. HeadPhones was also missing from the easy list, but I can live without that for now.
After what appeared to be a very long wait for software to install, I finally was able to start configuring everything that had previously been set up between the two boxes that were in use. A great part about the software being used, is that the configuration files are the same across platforms. Copy the files to the right locations, modify a few server calls to reflect the new ip address, and back in business like before.
The incredibly hard part was configuring Samba on the pi. This wasn’t because Samba is hard in itself, but more because I had a very outdated configuration file.
All told, the total time taken was just over 9 hours to get everything “close enough” which included forgetting that I mounted the USB drives under a home directory for a user I had yet to create and wasting 2 hours trying to get NFS working rather than troubleshooting to make my smb.conf file compatible with Samba 4.