Today I decided to get an inexpensive custom domain from Namecheap and try self-hosting Lemmy. A few bucks later I was thinking, “Hey, this is going to be cake.”
I’d read some of the warnings about Oracle Cloud free tier, but figured I’d still give it a shot for hosting. I found a simple how-to for quickly getting an Ubuntu instance spun up with Docker and Portainer. A few minutes later I’m thinking, “This is so easy!”
Then I try to access Portainer using HTTPS and see my first “Your connection is not private,” warning. “No worries,” I think. “Advanced>Proceed. I’m in.”
So I run Lemmy Easy Deploy. “The lights are green, the trap is clean! Boom. Here we go!”
Nothing.
Ports seem to be open on Oracle, but no Lemmy at either 80 or 443.
“Maybe Lemmy is more particular about SSL certificates and such?” I think, for the first time getting worried.
"Err, I think that if I change my nameserver to Cloudflare I can destroy my Lemmy containers, re-run Lemmy Easy Deploy with a Cloudflare API token, and maybe fix it?
Four hours later, after repeatedly starting over, clearing my browser cache every 5 minutes, switching back and forth between nameservers, even deleting the whole Oracle Cloud VM and starting from scratch, I realize that an HTTP connection to port 443 is returning “Client sent an HTTP request to an HTTPS server.”
“Were you there before, message?” I wonder.
Lemmy friends, can you help me? Or am I better off just deleting the VM and giving up the whole idea?
That’s not really the right approach on OCI, unfortunately: if you just flush the rules you also break a lot of their management plane.
You’d want to modify the /etc/iptables/rules.v4 and rules.v6 files to add any rules you want to load on boot (and, of course, if you just flush the rules without saving them, then it won’t persist and a reboot will break things, again).
It’s an arguable benefit: I’m a fan of having the security policies AND iptables sitting between me and doing something stupid, but I also spent most of the last decade dealing with literally thousands and thousands of compromised hosts that just whoopsie oopsed redis/jenkins/their database/a ftp service in a publicly accessible state, got hacked, then had the customer come crying to us asking why we didn’t keep them from blowing their foot off - which, basically, is what the OCI defaults do.
I agree with this, what I suggested is not a best practice, I should preface my post with that.
And I feel your pain! I get calls that are extremes, like people putting too much security where the ticket is “P1 everything is down, fly every engineer here” for an nACL/SG they created.
The other extreme is that deliberate exposure of services to the public internet (other service providers send us an email and ask us to do something about it, but not our monkeys, shared responsibility, etc).
Yeah, I just mentioned it because OCI is kinda wonky and requires some static routing stuff in the iptables on the host to have the platform work as intended (which, as far as I’m aware, no other hyperscaler does), which strikes me as really really lazy engineering, but I’m just a simple computer janitor so maybe I’m wrong there.
The most infuriating thing at my last job was people sending in a ticket freaked out that their database was stolen and ransomed, and us going ‘Well, we sent you 15 emails over the last 3 months telling you that you had the database open and improperly secured, so what exactly are you wanting us to do now?’