Jotted down my backup process for home. Spoiler: it's a bunch of SSDs sitting on top of a Raspberry Pi. But there's a few fun things in there too: raid, encryption, cron, make, rsync, ssh, Home Assistant and a tiny loaner dog. Enjoy.
Just on your first suggestion, this also means that if a person or process can drop a file (unknown to you) into your ~/bin/ then they can wreak havoc. Eg they can override `sudo` to capture your password, or override `rm` to send your files somewhere interesting, and so on.
Btw on the second suggestion, I think there's a command named `command` that can help with that sort of thing, avoids recursive pitfalls.
I used to self-host email, it was mostly all initial setup and then it just worked for years. Eventually I got a bit wary about the security side of an internet-accessible box and decided to move the whole thing over to AWS SES. Wrote it up here:
Good question. So one change I made last year was to cap the number of queues the free account could utilize. It's sort of hard to know for certain if that was what moved the needle though.
There has been a suggestion that maybe the free plan could just be a time-limited trial instead.
But it feels like there is some risk associated with that - as often a customer will use the free plan for (eg) six months, before hitting the limits and becoming a paid account.
But my takeaway was more like "Give yourself permission to be bad"
Felt good to be reminded that if you want to make interesting things, it's ok to flail around. It'll feel foolish and that's completely ok, perhaps necessary.
a) a cloud-based password service (eg 1password) or
b) a local-storage password database (eg pass, KeePassXC)
My preference is not to store personal account details with an internet accessible third-party (but I can see the value in it for an organization).
And with the local solutions, it doesn't really seem pleasant to manage, use, synchronize and backup password databases across multiple machines. Also it seems like you're just one laptop disk dying away from possibly losing credentials.
To be clear I'm not suggesting anybody should use my hacky script - the article is meant to be more like: "well I don't love this, but here's how I do things".
For many years I used an EC2 server for my personal email (running Debian and Postfix) but I recently decided it might be better to have one less internet-facing server to worry about.
This article documents the setup for AWS SES to handle incoming/outgoing mail delivery.
Yes concerning. The possibility of losing them between filesystems is worrying too.
One rule of thumb is `mv` will keep the attributes by default (given similar filesystem) and everything else needs tweaking/extra args. There's a section on it over here: