Building an Alpine NAS

Abandoning RHEL's Ship · July 16, 2020

For a few years I've been running a RHEL server for my bulk storage, and as a small home hypervisor. It started as RHEL7, upgraded to RHEL8, and honestly has been a wonderful experience to administer in a lot of ways. Red Hat goes well out of their way to provide a smooth experience.

However after the server being offline for months thanks to my recent move, and my RHEL subscription running out, I can't apply security updates or much of anything. Of course the system will keep running along just fine without those, but I don't think I can bring myself to just sit back and accept that. So it's good bye RHEL, hello more Alpine! As if I need even more excuses to run Alpine systems.

Amusingly enough that server was only truly hosting a few Alpine virtual machines for package maintenance/system development, and dockerized services, which were almost all Alpine based as well. In reality I barely used the "RHEL" components, outside of the fantastic Selinux configuration that's provided out of the box.

After the base installation I enabled the edge main/community repos, just to get access to some of the packages I maintain and dived right in. Right out the gate we need to install the basics.

All I truly need to get going in this list is emacs, docker, samba, and mdadm. My primary goal being to setup a RAID1 array on two 4TB discs, mount the resultant array to /data, and serve the file system using Samba. That entails user configuration, service configuration, monitoring configuration. Quite a bit. And on top of all of that I'm moving about a terabyte of data from the old array. So once the actual file system is rebuilt I've got sort and move all of the old data, make it compliant with the permissions I decide will be on the new file system. It all seems to get overwhelming pretty quickly, but in honesty it's pretty cut and dry!

Firstly I'll ensure that I have the RAID1 modules loaded and enabled when the kernel comes up.

Once we've loaded the kernel modules we can create the array. mdadm makes the entire process painless, we're really just passing our two discs to it, and then creating a file system on the resulting /dev/md0 array.

After that I can create my users, I'll just do me for now, but this should apply for all of my users in general.

Instead of trying to control directories per user, since this is just a home NAS, I went ahead and configured a catch all group. The Civis user group will be applied to all directories and files in the Samba drive, and anyone in that group will have read and write access to those files.

To explain this a little bit, enabling a mask of 0644 ensures that all files are served to anyone in the civis group as -rw--r--r--, and any directory as rwxrwx-rx. But the real magic happens with the group settings. When we set force group = civis, then any files created by clients will be automatically owned by the user & the civis group. That's to say if I access the NAS and create a file it'll show up as wsinatra:civis, if johnny does, it'll still show up as johnny:civis, and we can read and write both of those files. If you want tighter control than that you can create different directory shares and assign them to various groups, or any other access paradigm you wish.

Now since I'm migrating things that means I've got data to deal with. Fortunately sorted data, but lacking permissions for the new array. Once everything is copied over it's a simple process to fix things up.

Once we've set the permissions we should technically be done! Everything should work just fine as intended, but there's a couple of simple Quality of Life tweaks we can make to our new little NAS. Like a quick MoTD heads up system, auto updates, and array monitoring. There's plenty of ways to configure all of these, and below isn't what I would call an "enterprise" solution, but it's a great stop gap until I can get a Nagios container together.

To explain that briefly, we're using the OpenRC start scripts to ensure that anytime an msmtp service is started that we force /usr/sbin/sendmail to be overwritten by /usr/bin/msmtp. That's not strictly necessary, but it makes sure that we don't accidentally kick off sendmail by some weird accident.

And for our MoTD generator we'll use Atentu a little generator of my own design. The output is a simple load/memory/disc usage type deal, eventually I'll add service status and raid information to it. All of that said we can finally wrap everything up in a nice crontab bow.

We enable a few simple services to run, automatic updates (because we like to live on the edge!) (and can't be bothered to do this manually), our RAID monitor, and a reoccuring AV scan that kicks off at 11pm. We wouldn't want our Windows users catching anything nasty would we? Even if something that gets put on the NAS doesn't affect us directly, we should care about our users.

This post is a little longer than usual, but was the culmination of a poorly implemented personal server that gathered way too much cruft, a massive move from Georgia to Maine, and a pleasant feeling of confidence knowing that something like this is readily within my grasp.