• 2 Posts
  • 336 Comments
Joined 5 months ago
cake
Cake day: June 9th, 2024

help-circle


  • two commands: dd and resize2fs, assuming you’re using ext4 and not something more exotic.

    one makes a block-level copy of one device to another like so: dd if=/dev/source-drive of=/dev/destination-drive

    the other is used to resize the filesystem from whatever size it was, to whatever size you tell it (or the whole disk; I’d have to go read a manpage since it’s been a bit)

    the dd is completely safe, but the resize2fs command can break things, but you’d still have the data on the original drive, so you could always start over if it does - i’d unplug the source drive before you start doing any expansion stuff.








  • 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.









  • sudo smartctl -a /dev/yourssd

    You’re looking for the Media_Wearout_Indicator which is a percentage starting at 100% and going to 0%, with 0% being no more spare sectors available and thus “failed”. A very important note here, though, is that a 0% drive isn’t going to always result in data loss.

    Unless you have the shittiest SSD I’ve ever heard of or seen, it’ll almost certainly just go read-only and all your data will be there, you just won’t be able to write more data to the drive.

    Also you’ll probably be interested in the Total_LBAs_Written variable, which is (usually) going to be converted to gigabytes and will tell you how much data has been written to the drive.


  • As a FunFact™, you’re more likely to have the SSD controller die than the flash wear out at this point.

    Even really cheap SSDs will do hundreds and hundreds of TB written these days, and on a normal consumer workload we’re talking years and years and years and years of expected lifespan.

    Even the cheap SSDs in my home server have been fine: they’re pushing 5 years on this specific build, and about 200 TBW on the drives and they’re still claiming 90% life left.

    At that rate, I’ll be dead well before those drives fail, lol.