ebrahimh

I've never tried to set it up even though I know it can easily be done with things like mailcow.

The downside is never really knowing if your email reached your recipient (maybe it got blocked by Gmail because of your IP, maybe some other reason). If I use Gmail/proton etc, then I can be pretty sure that the other person got my email.

I actually don't use protonmail but you should be able to access your mail with IMAP (both iCloud and Gmail support it so proton should as well).

If by encryption you mean PGP etc, that's handled in roundcube I believe.

mbsync mirrors your protonmail inbox to disk, dovecot shares that mail folder through IMAP, and roundcube or some other frontend connects to dovecot.

For gmail/icloud IMAP, you can't use your regular account password, you have to create an "app password" and use that password for mbsync.

Good article. I have many of the same services in my setup.

Self-hosting email fully is tedious/unnecessary, but what you can do is mirror your various inboxes (Gmail, iCloud, proton, non-corporate outlook) with mbsync and use roundcube or some other frontend to view emails and compose.

I use this to easily access mail from different services, and I can also send from any of them.

I also have a seperate service that watches the mail directory and sends a ntfy.sh notification for new emails.

It’s a bit complicated cause theres so many services but here are the quadlets: https://github.com/ebrahim37/infra-template/tree/main/homela...

I implemented this about a month ago because the iphone Mail app was increasingly buggy.

I like CoreOS because of the fact that all config, etc files, sysctls are in one place.

Previously, I was using artix and had this “etc” directory[1] checked in to keep track of system configuration, but there was no good way to keep track of config drift (other than remembering to update this dir).

Haven’t gone through a CoreOS update yet (been using for ~2 months), but doubtful it would break anything. I’ve tested to make sure all my containers shutdown gracefully etc.

The SOPS (secrets.yaml) pattern is more common in NixOS configs, and I found it works nicely here too. In the artix setup, I had a bunch of .example files strewn around [2], which I had to remember to sync with the real versions.

Encrypting a key is just prefixing it with “enc_priv_”, SOPS will encrypt and decrypt it automatically. I keep “public” values plaintext to maybe help someone setting this up for themselves. Just have to double-check git diff before committing.

[1] https://github.com/ebrahim37/infra-template/tree/00eccff06ae... [2] https://github.com/ebrahim37/infra-template/blob/00eccff06ae...

I’m setting up 3-2-1-ish backups for my infra of 3 hosts, and definitely leaning towards Restic + Backrest.

All my hosts run the same CoreOS setup (https://github.com/ebrahim37/infra-template), where container volumes are placed in one central volumes/ folder and that is the only thing I have to backup.

I plan to implement it like this:

  vps1:
  - restic container with custom sh entrypoint that will backup volumes/ to homelab every 24 hours
  homelab:
  - backrest container, to back up volumes/, do prune/check, replicate repo to offsite
  - rest-server container, will store backups from vps1, homelab, offsite
  offsite:
  - restic container, backs up volumes/ to homelab every 24 hours
  - rest-server container, store copy of backups from homelab

Only caveat is backing up databases, will either have to do: stop container, backup volume/database-data, start container; or use pg dump etc.

The deduplication is nice, you can have a snapshot for each week of the past year without crazy storage cost

For a moment, I thought it was a reddit-style account birthday badge