Hacker Newsnew | past | comments | ask | show | jobs | submit | alance's commentslogin

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.


That would require someone to already want to sabotage me in particular, learn my private workflows, and also have write access to my home folder. At that point, All is Lost.

Don't tell people to sacrifice agency for apocalypse insurance that doesn't work, lol


If someone can drop a file in your ~/bin, they can also edit your shell’s startup files to add their malicious command.

I think it's already game over if they have access to your home directory. They can also edit your path at that point.

While true, what you describe is very unlikely to happen and most definitely won’t happens on systems where i’m the only users.

The issue of rootless malicious command overrides is solved by typing the whole path, such as "/bin/sudo".

No, don't do that as a precaution. As others have already answered correctly - it's too late to worry about such things if a malicious agent has write access to your ${HOME} dir.

Fwiw termux + rsync for android phone backup (eg rsync /storage/emulated/0/) will grab most things.

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:

https://alexlance.blog/email.html


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.


A talk about creating from Ethan Hawke called "Give yourself permission to be creative"

https://www.youtube.com/watch?v=WRS9Gek4V5Q

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.



It seems like the choices are:

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

Got another approach?


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.


Ha, it suddenly sounds like trouble.

Eg: one could piggy-back an entirely new file onto an existing file (it might have to be text encoded?).

It looks like the kernel might impose a limit of 64KiB on a file's metadata, but that's still quite a lot of room for data smuggling...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: