My experience is similar. I no longer use dedicated NAS, firewall, or other exotic distributions. I run plain Debian, and add what I need through standard repo packages. My "NAS" is simply a Samba daemon. The same box runs countless other services including hostapd (WiFi), DNS (Unbound), an email stack (Postfix/Dovecot), multiple game servers, and Podman.
> everything else in Docker Compose
I would suggest Podman instead. It is far more secure by design (rootless) and is unable to silently alter the firewall's configuration.
I'd like more informations about this as I'm not too familiar with firewall setup but every time I tried to setup iptables / nft it was indeed bypassed by docker. Recently I found out in the docs that docker adds a DOCKER-USER table, isn't it enough to put your rules in it to prevent the outside world to reach containers ?
I used btrfs raid0 on USB drives for more than a year. Every month or so, a drive would disconnect from the bus and immediately redetected as another device (sde->sdf). Btrfs does not auto-recover from this. The choices are 1) reboot and scrub, which recovers the missing drive without doing a full resync, but it needs a reboot (any hosted site is offline for 3 minutes) and scrub takes a long time reading in the background, or 2) run btrfs replace which doesn't need a reboot, but the full resync takes even longer than a scrub and increases wear if it's a ssd because it wipes everything and writes all data again.
Though I really don't use the server anymore and it's probably worth several thousand dollars with the RAM in it. Been thinking of using a spare laptop with external HD bays to do the same job.
Realtalk: make sure you are religious about testing your RAM if you're going to run ZFS with non-ECC RAM. I'm not going to say “don't do it”, but know what you're getting into and how to protect yourself from this failure mode.
It's unintuitive, but ZFS will actually modify your files on disk as a side effect of a read-only operation if blocks get read into bad RAM and checksum mismatch compared to the blocks on disk.
This happened to me in 2013–14 with some bad PC3 10600 in my 2600K desktop FreeBSD system, and it rotted a bunch of my most frequently accessed files. I was able to figure out what was going on once audible blips started appearing in all of my favorite most-listened-to music, then I learned about `flac -t` and was able to confirm the rot thanks to the fact that FLAC files embed an expected MD5 digest in their `STREAMINFO` block. `man flac` sez…
“In test mode, flac acts just like in decode mode, except no output file is written. Both decode and test modes detect errors in the stream, but they also detect when the MD5 signature of the decoded audio does not match the stored MD5 signature, even when the bitstream is valid.” (emphasis mine)
[Lammy@popola] flac --test "Floating Door - Hypersomnia in loop - 12 templeOS.flac"
Floating Door - Hypersomnia in loop - 12 templeOS.flac: ok
[Lammy@popola] metaflac --show-md5sum "Floating Door - Hypersomnia in loop - 12 templeOS.flac"
d9ccdc78cfa45dda01b38198575b4f56
[Lammy@popola] flac --decode --stdout --silent --force-raw-format --endian=little --sign=signed "Floating Door - Hypersomnia in loop - 12 templeOS.flac" | md5
d9ccdc78cfa45dda01b38198575b4f56
I'm wondering what:
- the failure mode is if it can't provide enough current.
- How to properly test it under a fake load
- If these tiny power cables can really handle 150 W (this is 12 A at 12V). I don't have such a powerful 12V PSU, so I am thinking about adding capacitors to handle transients.
I imagine that it is really built to handle transient peaks to 150 W, with a more reasonable baseline.
Anyway, if anyone knows a good knowledge source for these PSU, I'd be interested.
My initial motication for going with these was:
- hopefully increase my PSU efficiency
- less cable clutter
- hopefully power it from a small DC UPS (there are plenty of "router" UPS sold on the market, though the power rating is a bit low, 18-36 W usually).
Measurements are not accurate, but comparable. I used a Tasmota smart plug - the same one in both cases.
(Edited to add: I forgot! ZFS on root available from the installer -- encrypted even if that's your jam.)
I broadly approve, but why Kubuntu? Isn't it headless?
Not sure why they claim to have written the dashboard themselves though. It’s clearly vibe-coded, I did that too and mine is almost identical.
But I'm not as convinced as the article's author that "NAS" is outdated as a separate concept, just that as new people learn more about networking they rediscover why just having storage on in its own box can be a good setup. And when new people are brand new, having everything on one box is conceptually simpler, though not always optimal.
I think, in the family/household context, I like the names:
Homelab: the box/cluster you use to experiment and test new stuff.
Homeprod: the box/cluster you use to deploy stable services for family. Runs only things that have graduated from at least a yearlong successful deployment or so on homelab.
Homebase: the box/cluster you use to make ZFS pools and databases available to both homelab and homeprod (on the same network or overlay network). Basically a NAS in the older sense of the word, before homelabs started expanding its scope in casual use.
Famadmin: the sysadmin for the family (i.e. "you" in the three items above). The person to whom, as you say, "providing services that support your family's larger existence, independent of the surveillance industry," is a matter of deep principle. And well put, BTW.
Everyone who builds this should really have "homeprod" and "homelab". And when the experiments and tests inevitably lead to an outage, the movie streaming or photo storage or home control parts don't die with it.
https://en.wikipedia.org/wiki/Spin-up#SATA_and_PATA
Of course it's a lottery if it would work on a kitbashed homelab case.
I will point out that if you use ZFS instead of btrfs, you can specify drives to be detected via their serial number names rather than their attachment points, so a reconnect will not require a reboot.
Still, don't depend on USB for anything meant to be permanently connected.