Personally, I wouldn’t bother wiping the asustor. There’s nothing wrong with OpenMediaVault, but it’s not any more straight forward than TrueNAS. If you’re looking for beginner simple, maybe something like HexOS or CasaOS would be more to your liking. But that makes me wonder about Proxmox for this setup. I love Proxmox and use it extensively at home and at work. It’s incredibly powerful and flexible, but it’s a lot less hand-holdy than TrueNAS. By all means give them all a try—thats the fun—but expect a learning curve before things really click.

This sounds like a very fun project. I also run a small local news organization and we use a company that specialize in managing small news sites (Our-Hometown.com, in case you want to give them a look). We’ve been very happy with their service for the past 25 years, so I don’t plan on leaving them any time soon, but, as a self-hoster, I’ve also spent a lot of time thinking about how I’d put together the infrastructure. I think my preference is Nginx plus Varnish for caching. Also, in case you’re not aware of it, Automattic makes a plugin for newsrooms that adds some industry-specific features (https://github.com/Automattic/newspack-plugin) that looks interesting, though I haven’t tried it.

Lee Hutchinson at ArsTechnica wrote an interesting series about hosting a weather news site in Houston that I thought was awful interesting and might be worth a read. Here’s part 1 and part 2.

Sure. For full disclosure, I also run separate compute and storage. I do think separating storage from a compute cluster can be a good option, but not necessarily for the use case described in the original question.

I’d recommend against separating storage and compute in most small environments. Separating them means you suddenly have higher latency and less bandwidth between your data and whatever you want to do with it. Sure, there are good reasons to do it (centralizing storage for multiple nodes, for example), but go into with your eyes open to the trade-offs.

I landed on KDE and I don’t worry about it matching my Mac desktop, though you certainly could. The thing I miss most is the Finder, oddly. There’s not much in Linux world that gives Miller columns, unfortunately.

I’ll mention that if you like your Mac keyboard, or just want to keep using the familiar shortcuts, check out Toshy. It remaps the keys so that command still does what you expect it to do.

Here’s one more opinion for you.

Running a NAS on Debian is a great idea if you don’t mind being responsible for all of the details that TrueNAS abstracts away. One thing I’d consider in your shoes is to use Proxmox VE rather than vanilla Debian. I say this because PVE uses a kernel with ZFS built in, so there’s no fiddling with DKMS to get it to work; it just treats it as a first-class file system (including on root). Having said that, either is a perfectly good choice.

If you want a UI, I’d heartily recommend Cockpit, which is included in the repos (just apt install cockpit). If you go the PVE way, you’ve got a couple options. You could either virtualize your existing TrueNAS, passing through the disks or (and this is my preference) let the host handle all the ZFS stuff and create an LXC container that just deals with filesharing. You’d bindmount a directory from the host that could be shared out via SMB and this is where I’d use Cockpit to manage the shares.

The PVE route makes adding VMs and containers pretty quick. I haven’t run into any issues passing through a GPU to either a VM or LXC, which can then be used inside a docker container.

In answer to the common pitfalls question, I think the biggest thing I see is that it’s important to document exactly what TrueNAS is doing for you. Did you encrypt the ZFS pool? Make sure you have the keys to unlock it and arrange for your next OS to do so gracefully. Are you managing snapshots and replication in TrueNAS? Document and adapt that. Something like sanoid/syncoid can manage this on a Debian system. How about monitoring? Don’t forget to set up notifications for disk failures. Any other services you’re using? NFS, iSCSI, cronjobs? Take care notes of everything because that’s the stuff that’ll be easy to miss if you jump straight to overwriting your old boot disk.

Way to go!

Yes absolutely. I must’ve misinterpreted what you said. What did you mean by “not visible anymore over the network.”

I’ve only used dropbear on openwrt systems, but I’m pretty sure it doesn’t use the '/etc/ssh/sshd_configfile. The alpine wiki says the config file is at/etc/conf.d/dropbear`.

That bit about the pi not being visible in the network after reboot makes me wonder if this is more of a networking issue rather than an ssh one.

The pi zero is WiFi-only, right? Can you confirm that it’s getting on the WiFi network successfully? If so, maybe it’s getting a different IP than it initially did via DHCP.

The way I handle this is to have two VMs running in separate hosts, each running my reverse proxy along with keepalived. I resolve my subdomains to the keepalived shared address and then keep the reverse proxy config in git with a cron job to pull updates.

I pretty much stick to straight bash and core utils, so it’s not much of a burden. Plus on the Linux side, I mostly stay with Debian and its derivatives, which limits some of the work.

But really I don’t consider every feature of my dot files to be a finished product. The core stuff is reliable, but if I catch a problem with anything more esoteric or if I see some functionality that looks interesting, it’s a brain teaser I get to tackle.

I do a git repo for my dot files with an installer that configures it based on whether I’m using Linux, macOS, or FreeBSD; a server or desktop; and whether I’m in bash or zsh. It also includes a bunch of functions and aliases that I find useful. It’s not always pretty because I also use it as a practical place to try new shell script bits when I have time. I’m hoping to change some things around soon thanks to some ideas from Dave Eddy’s bash course at ysap.sh.

Great idea; these are nice little machines. I have one running as part of a Proxmox cluster. I recall that there was some rigamarole to get it installed because of the T2 security chip that comes in that vintage of Mac. I’ll check my notes and see if I can find how I handled that.

If I remember correctly, that was largely in consideration of the large corpus of docker-packaged projects that could be used as a pre-built app ecosystem. That makes a lot of sense for anyone who really wants an appliance-like all-in-one system with minimal setup.

That’s certainly true in terms of TrueNAS Core, but FreeBSD itself is quite active (15.0-RELEASE dropped this month), as are the others BSDs.

I’m not sure what it is, but Scale has never thrilled me. I’ve tested it a couple times and I just didn’t get along well with it. I’ve tested know Jim Salter (practicalzfs.com) has frequently recommended XigmaNAS as a strong (albeit less pretty) alternative to TrueNAS. I did some tests with that as well and it seemed perfectly fine. In the end I decided that when I migrate off of Core this winter, it’ll be to a bare metal FreeBSD system. I’m using it as an excuse to better learn that ecosystem and to bone up on ansible, which I’m using to define all of my settings.

There’s lots of good stuff on YouTube, including from David Bombal and Jeremy Cioara. If you’re more of a listening-while driving person, years ago the Security Now podcast did a “how the internet works” series that gives a terrific overview of the TCP/IP stack (it’s from 2006, but it’s still very applicable). And if you like to read, Michael Lucas just released a “Networking for Sysadmins” book, which is excellent.

To my thinking the most important difference would be mobility. Using the Synology app would probably make setup somewhat easier, but if you ever decided to leave the Synology ecosystem migration would likely be more complicated. That by itself isn’t a recommendation one way or another, but it should definitely factor into your planning.

Sure thing—autofs is a pretty cool utility and it works with SMB as well.

If the storage isn’t present for PBS, the backup would fail. There are files inside the directory that PBS will notice are missing.

Mounting the NFS export in the PVE host is the simplest way to get shared storage into an LXC container. You have to fight apparmor to mount NFS or SMB inside the container directly.

No, I used an unprivileged container and I set the permissions on the NFS server to accommodate that.