• 3 Posts
  • 200 Comments
Joined 6 months ago
cake
Cake day: June 9th, 2024

help-circle












  • good ideia to run restic as root

    As a general rule, run absolutely nothing as root unless there’s absolutely no other way to do what you’re trying to do. And, frankly, there’s maybe a dozen things that must be root, at most.

    One of the biggest hardening things you can do for yourself is to always, always run everything as the lowest privilege level you can to accomplish what you need.

    If all your data is owned by a user, run the backup tool as that user.

    If it’s owned by several non-priviliged users, then you want to make sure that the group permissions let you access it.

    As a related note, this also applies to containers and software you’re running: you shouldn’t run docker containers as root unless they specifically MUST have a permission that only root has, and I personally don’t run internet facing ones as the same user as all the others: if something gets popped, then they not only do not have root permissions, but they’re also siloed into their own data in the event of a container escape.

    My expectation is that, at some point, I’ll miss a CVE and get pwnt, so the goal is to reduce how much damage someone can do when that happens, rather than assume I’m going to be able to keep it from happening at all, so everything is focused on ‘once this is compromised, how can i make the compromise useless to the attacker’.


  • Unifi Gateway Ultra

    How have you liked the gateway? Any stupid decisions that have annoyed?

    My USG has decided that, after a decade, it’s going to be flaky and crash if it wants to (even after replacing it’s 4th dead PSU and 2nd USB stick) and I’m thinking it’s probably time to upgrade.

    I’ll admit to both liking the Unifi ecosystem and firmly not trusting the Unifi ecosystem one damn bit, which is bit of a weird situation where I’ve been really really unwilling to upgrade anything because that hasn’t always gone uh, smoothly.




  • I mean, recovery from parity data is how all of this works, this just doesn’t require you to have a controller, use a specific filesystem, have matching sized drives or anything else. Recovery is mostly like any other raid option I’ve ever used.

    The only drawback is that the parity data is mostly equivalent in size to the actual data you’re making parity data of, and you need to keep a couple copies of indexes since if you lose the index or the parity data, no recovery for you.

    In my case, I didn’t care: I’m using the oldest drives I’ve got as the parity drives, and the newer, larger drives for the data.

    If i were doing the build now and not 5 years ago, I might pick a different solution but there’s something to be said for an option that’s dead simple (looking at you, zfs) and likely to be reliable because it’s not doing anything fancy (looking at you, btrfs).

    From a usage (not technical) standpoint, the most equivalent commercial/prefabbed solution would probably be something like unraid.


  • A tool I’ve actually found way more useful than actual raid is snapraid.

    It just makes a giant parity file which can be used to validate, repair, and/or restore your data in the array without needing to rely on any hardware or filesystem magic. The validation bit being a big deal, because I can scrub all the data in the array and it’ll happily tell me if something funky has happened.

    It’s been super useful on my NAS, where it’s the only thing standing between my pile of random drives and data loss.

    There’s a very long list of caveats as to why this may not be the right choice for any particular use case, but for someone wanting to keep their picture and linux iso collection somewhat protected (use a 321 backup strategy, for the love of god), it’s a fairly viable option.