Building a Home Server
In this article, I’ll document my process of building a home server - or NAS - for local storage, smb drives, backups, processing, git, CD-rips, and other headless computing.
Why a Home Server?
The necessity of a NAS these days can be questioned, given the cheap - or free - availability of cloud storage. However, getting into a dependency with an external vendor poses significant security risk for individuals that do not enjoy the same benefits a corporate account with big bills might receive, notably -
- Changes in storage tiers and costs (see Flickr limiting free user’s storage tier to 1,000 photos, from previously 1TB or Microsoft dropping unlimited storage for OneDrive - especially fun if you already have gigabytes, if not terabytes, stored there)
- Upload capacity with broadband connections (except for Google Fiber, no American ISP offers symmetric up/down links) - uploading my CD vinyl collection, even ripped as compressed MP3s @ ~70GB, would take me a easily half a day - (not to mention my 2TB Steam collection) and that is only a fraction of our available local storage)
- And hence, high-speed backups from all local devices, such as PCs, Macs, Routers, etc.
- Privacy concerns - while you can, naturally, uploaded encrypted files, you lose the benefit of automatic syncing in most cases
- Flexibility to run additional services such as a pi-hole (DNS ad blocker), monitoring software, local build server and git repositories, or VPN services
- Service outages on cloud services or your local internet
However, for the record - the server where you reading this article on does get backed up to AWS S3 via an encrypted duplicity backup (which is neither free nor user-friendly). There is no “one size fits all” solution.
As a preliminary note: Do not copy paste any of the commands without making sure all parameters match your system’s configuration!
- CPU: AMD - Ryzen 3 2200G 3.5 GHz Quad-Core Processor
- Motherboard: Gigabyte - GA-AB350-GAMING 3 ATX AM4 Motherboard
- Memory: 2x Corsair - Vengeance LPX 8 GB (1 x 8 GB) DDR4-2400 Memory
- Storage: Western Digital - Green 240 GB M.2-2280 Solid State Drive
- Storage: 2x Western Digital - Red 6 TB 3.5” 5400RPM Internal Hard Drive
- Storage: 2x Western Digital - Red 3 TB 3.5” 5400RPM Internal Hard Drive
- Power Supply: EVGA - SuperNOVA G3 550 W 80+ Gold Certified Fully-Modular ATX Power Supply
- Case Fan: 2x Noctua - NF-F12 PWM 54.97 CFM 120mm Fan
- Case Fan: 2x Noctua - NF-R8 redux-1800 PWM 31.37 CFM 80mm Fan
- Case: Rosewill RSV-R4000, 4U Rackmount Server Case / Server Chassis, 8
The total price (as of 2019-04-06) is roughly $1,200 USD.
I’ve also added some existing hardware, like 2x 1TB Samsung HDDs and a PCI-to-SATA extension card.
Make sure you have the follow tools available -
- A laptop or desktop running any GNU/Linux or MacOS (Windows instructions differ - you will need an ssh client like putty or MobaXTerm as well as unetbootin to burn the ISO)
- An ethernet cable
- A keyboard
- A screwdriver
- A USB thumb drive
- All server hardware
- (Optional) Small LCD screen and spare keyboard to access the drive if SSH won’t work for some reason
First, we’ll get ourselves a Debian 9 ISO and burn it to a USB Thumb Drive. Other operating systems are available - I like Debian for it’s stability and easy maintenance and already run several Debian boxes.
This step is fairly straightforward. Assemble the hardware, plug in it, and make sure it posts. In the process, make sure the room you are using to assemble the system looks like a tornado went through it.
Cable management optional
Install Operating System
With your hardware connected to a screen, keyboard, and ethernet, it’s time to install the OS. Insert the flash drive, boot into it on the server hardware, and install Debian. I used my M.2 SSD with separate /home and /tmp partitions and enabled disk encryption with LUKS.
Once the installation is completed, we can set up the software.
First, we need to configure our network. Take a backup of the configuration and edit the file with vi:
Something like this should be the content for your interface file:
Keep in mind that your IP configuration might be different. Since I am running a pi-hole on IP 192.168.1.176, my DNS configuration refers to that server. For your environment, you probably want to go with 188.8.131.52 and 184.108.40.206 as DNS tuple. You can always check on your other devices via $ ifconfig or similar commands.
Next, we’ll configure the hostname and host resolution and restart the network service.
My hostname is “bigiron”, which might or might not be a Marty Robbins and Fallout reference. You can choose whatever you like.
Before doing anything, we’ll restart the network service and test the connection. Make sure you can reach google.com.
Then, we’ll update our packages and install all required software:
The software we need to install here is fairly standard - zsh is going to be our shell, vim serves as editor, git is used to handle repositories, openssh-server is used for SSH connection, wget & curl are used for downloads and network tests, cryptsetup and mdadm are used for disk encryption and RAID arrays, and the samba dependencies are for file shares.
Disclaimer: There is a known vulnerability for wget, CVE-2019-5953.
There is a known vulnerability for wget, CVE-2019-5953
Next, we’ll configure oh-my-zsh, a neat little wrapper around zsh that is my default shell on all *NIX boxes.
Now, we need to configure ssh to use the system remotely from our other machine.
Add the following content (using your user name) and restart ssh. Please make sure you configure public/private key authentication in due time.
Hard drive setup
Congratulations, your system is now operational. Granted - it doesn’t do anything. But we’ll change that in a spiffy!
You can now connect to your system using SSH (which is what we are going to do).
One of our most command commands is going to be the following:
This shows us the physical disks in the system, as well as their partitions. As I’ve mentioned before - do not simply copy paste these commands. Otherwise you will risk losing data and messing up your system.
Make sure you always take note of your disks’ identifiers (e.g., /dev/sda) and UUIDs.
Do not copy paste any of the commands without making sure all parameters match your system’s configuration
With that out of the way, we will need to add partitions to our first set of hard drives and format them. This will delete all data on the disks.
Once that is done, we need to create our RAID-1 array as such. We use RAID-1 to protect ourselves against disk failures. A RAID-1 array protects against drive failures - it is not a backup!
A RAID-1 array protects against drive failures - it is not a backup!
You can check the configuration as well as the sync status of your RAID-1 array as such:
Encryption with LUKS
Then, we’ll add LUKS encryption to the array:
Once that is done, we’ll add a key file to make sure we don’t need to punch in the password every time.
This this step, I am using an external USB thumb drive and hence am mounting /dev/sdd1 to /mnt/usb. You can also keep the key file on the system, but that would invalidate the point of having an encrypted disk in the case of theft.
Wonderful. Now, let’s make sure that the thumb drive containing the key gets mounted on boot by editing /etc/fstab
Then, we need to add the actual encrypted disk to /etc/fstab as well as /etc/crypttab.
In my case, I have only enabled this for the data drives, not for the boot drive. This is a matter of personal preference - I have a small 7” LCD on the 19” rack, including a keyboard, and simply punch in the LUKS key code on reboot. This won’t work you are not home, but leaving the thumb-drive in the system while you are away won’t help theft prevention of data. Feel free to send me your own best practices.
With all that done, you can test the setup by mounting everything in /etc/fstab by running:
Repeat this process for every RAID array in the system. In my case, that would be 2.
Furthermore, to persist names for existing arrays, follow these steps:
On a side-node - if you have existing drives, for instance from your desktop PC, make sure to back up all your data to a different disk, as setting this up will delete all data. You can do this as such:
On a related note, since I transferred an existing RAID-1 array, I had some massive drive issues that resulted in odd behavior (like timeouts on the READ() call in the kernel, as followed by strace - please don’t ask me why) - if you want to debug issues like these, the following commands might come in handy.
You can see the files being accessed by commands like rsync or cp through /proc with the specific PID of a process:
Also, using strace, you can debug very odd, low-level issues like mine:
Now, we’ll set up network shares with samba. This will allow all devices in the network to access shares on the server.
All we need to do is add a new user for samba (as smb users are separate from the host system’s users), backup our samba configuration and add shares, including valid users as such:
Test your setup by mounting the smb drive on a different computer. The below example is for Arch Linux. Replace the username and password accordingly.
Add a secured, read-only file for root to store your passwords:
And try connecting:
Mounted drive on Arch Linux with KDE
I hate to admit it, but Windows makes it a bit easier. :) Please see below for the steps (for Windows 10 Pro):
Right-click on “This PC” and “Map network drive”
Mapped Drive (the size might be off - this happened due to invalid permissions)
Last but not least, we’ll enable automatic updates for a GNU/Linux machine.
This is done with an encrypted duplicity backup. Make sure you store your GPG keys somewhere secure, like an encrypted USB drive.
You can know schedule this with cron (the below command will run it every day at midnight):
There are a lot more steps that you can take to make your server fully operational.
Here are some ideas -
- Plex or other home media shares to access your media on e.g. your AppleTV
- Running your own git server
- Running your own build server
- Running nextCloud
- Enabling wireguard or other VPNs for external access
- Enable rotating logs and log-backups
- Enable a duplicity backup pipeline to an external hard drive to safeguard against fires, electrical issues, or theft (a RAID-1 array protects against drive failures - it is not a backup!)
Furthermore, I strongly recommend setting up the following security best practices:
- Enable ssh login via public/private keys only
- Enable apparmor to restrict service account’s permissions (this can be very, very time intensive and may break existing software)
- Enable proper iptable rules
- Secure your outgoing and incoming ports on your router and physical network (switches)
- Secure your samba configuration
Running a home server can be taxing on free time and costs, but does allow for some powerful computing capabilities in your own home. Following similar steps like the ones highlighted above allow you to properly own your data, have control over your backups, and be independent of Cloud providers.
It is also a wonderful learning experience for everyone who has interest in GNU/Linux and Sysadmin tasks, but doesn’t want to be limited to small computing power (Raspberry Pi) or purely on fun projects (like running a barebones Debian on an old laptop).
While a regular external hard drive for Backups and Cloud services for anything else might be plenty for most people, if you have the energy to be your own admin, I can highly recommend putting a 19” rack in your house.
Disclaimer: In case you are married, you might need couples counseling after putting 100lbs of solid steel and a plethora of ethernet cables in your office.