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 ?
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.
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.
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.
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).
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
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.
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 broadly approve, but why Kubuntu? Isn't it headless?
[deleted]
[dead]
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.
I've wondered if my experience is different because I'm using single disks (but still ZFS) instead of any RAID. There is rarely transfer happening across all of the disks.
Unfortunately, where I need it the most - the router which is also a NAS - can't use directly-powered USB HDDs. Not enough ports. I had to use a hub. I tried 4 models, two self-powered and two powered by router's USB, and none of them was stable. I also tried 3 models of USB-SATA adapters. Two self-powered, one powered by hub (connected to the hubs that had separate power - didn't work otherwise). None of them was stable. It was always the USB-SATA adapters/racks that disconnected, not the hubs.
Then I bought a mPCIe 4-port SATA controller, Marvell chip. Didn't work. It freeze randomly and woudn't even unfreeze with a router reboot. Possibly too much power draw. Then I put a 2-port SATA, ASM1062 and a port replicator. That one works. 2 years and not one disconnect. The cables are a complete mess.
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.
Maybe the division is more apparent if you're using containers, and/or have more of a social group to communicate support levels to? Personally I'm just using NixOS and am still at the stage of "I'm going to reboot the router now, it might take ten minutes or it might take days" [0]
If we don't need this distinction, then perhaps "homebase" could actually make more sense than "homeprod" ? Slightly different connotations, less putting on a show for lots of people but more homey like for a small family?
[0] from a technical perspective I'd love to separate the router out onto its own machine, but I want fast wireguard/openvpn/TOR/etc so it's a VM on a larger machine and I'm not really looking to expand my power consumption footprint to another large machine. I suppose I could split it out to two routers, one with straight NAT+wireguard and one with openvpn/TOR/etc, then the main could run on its own low-power box.
My prod (now homeprod, thanks for the name!) has no HDDs, just SSDs. It's a proxmox cluster that runs opnsense in a VM for the whole network, Home Assistant also in a VM[1], and most other services in containers. In the age of expensive storage, it has just enough SSD space for VMs and containers. VM backups live on homebase, except for opnsense which also needs a backup on the same machine (same machine, not just same cluster) if the network goes down.
So my conceptual distinction is mostly that the only services/containers I put on homebase are doing work that really benefits being that close to the data. Oh, and I'm in the jolly position of needing to replace the hard drives this or next year. Yaaaaay.
My homelab is currently a cluster of 4GB Pis that I had lying around from before even the Raspberry Pi shortage. Whenever I upgrade my Framework 13 mainboard, I'll probably use the old one as a homelab instead of the Pis.
[1]: Home Assistant's plug-ins are themselves containers, so it's a good idea to give it either a VM or its own machine.
Measurements are not accurate, but comparable. I used a Tasmota smart plug - the same one in both cases.
Anyway, it may be a transient that I am measuring, as the PC turns off during the boot sequence, after the CPU fan starts revving up. My 5A PSU may not be enough, I'll try limiting the TDP and the power brick.
Some power bricks are not up to the specs written on them. Get one of those USB power testers that have a barrel plug too. They're very informative in cases like these.
(Edited to add: I forgot! ZFS on root available from the installer -- encrypted even if that's your jam.)
The Terramaster one is pretty widely used in home setups and seems perfectly fine.