move static files into static sub-dir, refactor nix a bit

1 files changed, 0 insertions, 115 deletions

diff --git a/src/_posts/2021-07-06-maddy-vps.md b/src/_posts/2021-07-06-maddy-vps.md
deleted file mode 100644
index 93c76d2..0000000
--- a/src/_posts/2021-07-06-maddy-vps.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: >-
-    Setting Up maddy On A VPS
-description: >-
-    We have delivery!
-tags: tech
-series: selfhost
----
-
-In the previous post I left off with being blocked by my ISP from sending
-outbound emails on port 25, effectively forcing me to set up [maddy][maddy] on a
-virtual private server (VPS) somewhere else.
-
-After some research I chose [Vultr][vultr] as my VPS of choice. They apparently
-don't block you from sending outbound emails on port 25, and are in general
-pretty cheap. I rented their smallest VPS server for $5/month, plus an
-additional $3/month to reserve an IPv4 address (though I'm not sure I really
-need that, I have dDNS set up at home and could easily get that working here as
-well).
-
-## TLS
-
-The first major hurdle was getting TLS certs for `mydomain.com` (not the real
-domain) onto my Vultr box. For the time being I've opted to effectively
-copy-paste my local [LetsEncrypt][le] setup to Vultr, using certbot to
-periodically update my records using DNS TXT challenges.
-
-The downside to this is that I now require my Cloudflare API key to be present
-on the Vultr box, which effectively means that if the box ever gets owned
-someone will have full access to all my DNS. For now I've locked down the box as
-best as I can, and will look into changing the setup in the future. There's two
-ways I could go about it:
-
-* SCP the certs from my local box to the remote everytime they're renewed. This
-  would require setting up a new user on the remote box with very narrow
-  privileges. This isn't the worst thing though.
-
-* Use a different challenge method than DNS TXT records.
-
-But again, I'm trying to set up maddy, not LetsEncrypt, and so I needed to move
-on.
-
-## Deployment
-
-In the previous post I talked about how I'm using nix to generate a systemd
-service file which encompasses all dependencies automatically, without needing
-to install anything to the global system or my nix profile.
-
-Since that's already been set up, it's fairly trivial to use `nix-copy-closure`
-to copy a service file, and _all_ of its dependencies (including configuration)
-from my local box to the remote Vultr box. Simply:
-
-```
-nix-copy-closure -s <ssh host> <nix store path>
-```
-
-I whipped up some scripts around this so that I can run a single make target and
-have it build the service (and all deps), do a `nix-copy-closure` to the remote
-host, copy the service file into `/etc/systemd/service`, and restart the
-service.
-
-## Changes
-
-For the most part the maddy deployment on the remote box is the same as on the
-local one. Down the road I will likely change them both significantly, so that
-the remote one only deals with SMTP (no need for IMAP) and the local one will
-automatically forward all submitted messages to it.
-
-Once that's done, and the remote Vultr box is set up on my [nebula][nebula]
-network, there won't be a need for the remote maddy to do any SMTP
-authentication, since the submission endpoint can be made entirely private.
-
-For now, however, I've set up maddy on the remote box's public interface with
-SMTP authentication enabled, to make testing easier.
-
-## Testing
-
-And now, to test it! I changed the SMTP credentials in my `~/.mailrc` file as
-appropriate, and let a test email rip:
-
-```
-echo 'Hello! This is a cool email' | mailx -s 'Subject' -r 'Me <me@mydomain.com>' 'test.email@gmail.com'
-```
-
-This would, ideally, send an email from my SMTP server (on my domain) to a test
-gmail domain. Unfortunately, it did not do that, but instead maddy spit this out
-in its log:
-
-> maddy[1547]: queue: delivery attempt failed        {"msg_id":"330a1ed9","rcpt":"mediocregopher@gmail.com","reason":"[2001:19f0:5001:355a:5400:3ff:fe73:3d02] Our system has detected that\nthis message does not meet IPv6 sending guidelines regarding PTR\nrecords and authentication. Please review\n https://support.google.com/mail/?p=IPv6AuthError for more information\n. gn42si18496961ejc.717 - gsmtp","remote_server":"gmail-smtp-in.l.google.com.","smtp_code":550,"smtp_enchcode":"5.7.1","smtp_msg":"gmail-smtp-in.l.google.com. said: [2001:19f0:5001:355a:5400:3ff:fe73:3d02] Our system has detected that\nthis message does not meet IPv6 sending guidelines regarding PTR\nrecords and authentication. Please review\n https://support.google.com/mail/?p=IPv6AuthError for more information\n. gn42si18496961ejc.717 - gsmtp"}
-
-Luckily Vultr makes setting up PTR records for reverse DNS fairly easy. They
-even allowed me to do it on my box's IPv6 address which I'm not paying to
-reserve (though I'm not sure what the long-term risks of that are... can it
-change?).
-
-Once done, I attempted to send my email again, and what do you know...
-
-![Success!](/assets/maddy-vps/success.png)
-
-Success!
-
-So now I can send emails. There are a few next steps from here:
-
-* Get the VPS on my nebula network and lock it down properly.
-
-* Fix the TLS cert situation.
-
-* Set up the remote maddy to forward submissions to my local maddy.
-
-* Use my sick new email!
-
-[maddy]: https://maddy.email
-[le]: https://letsencrypt.org/
-[vultr]: https://www.vultr.com/
-[nebula]: https://github.com/slackhq/nebula