AlexanderESmith

Not a lawyer: I’ve never seen it be an issue if whoever’s running the site isn’t pretending to be something they’re not. Take that for what you will.

To add to this; I’ve done some corporate work in this area as a systems admin. If something like this comes up (within the context of being a representative of a company that finds out that someone has a domain that we may hold rights to), one of the things I’ve been asked to do is submit a “Uniform Domain-Name Dispute-Resolution Policy” (UDRP) complaint to ICANN (icann.org - Internet Corporation for Assigned Names and Numbers). They basically regulate domain usage and ownership, among many other things.

To read about how these complaints work, see; https://www.icann.org/resources/pages/help/dndr/udrp-en

Read that over while deciding whether you want to use the domain and how you use it. Give particular attention to https://www.icann.org/resources/pages/udrp-rules-2024-02-21-en , section 3-b-ix (titled “Describe, in accordance with the Policy, the grounds on which the complaint is made…”), and it’s sub-items.

There’s a whole lot of advice here, and practically none is it is aimed at a beginner. You don’t need a reverse proxy or SSL to get started.

1. Install the OS - You’ve done this already.
2. Install some kind of http server - Apache is fine, people recommending anything else are overcomplicating. The package is called either apache2 or httpd, depending your flavor of Linux.
3. Put your files in the web root - Usually /var/www/html/. If the file is something like index.html, it’ll load as the default page without having to type http://youraddress/index.html
4. Restart Apache - different across OSes, Google will get you there. Something like systemctl restart httpd, but “systemctl” might be “service”, and “httpd” might be “apache2”.

Once you’ve done that, you have a computer that will serve your html files when someone hits http://[yourIP]/ . At this point, make sure your router/etc is allowing connections on port 80 (the http port), specifically to that one computer. Also, don’t allow that computer to connect to the rest of your home network (not getting into a step-by-step here; every home network uses different hardware), because now that the Internet can touch it, it’s a target for hackers. If all they can touch is this one computer (start calling it a server), the risk is minimal.

If you want to point a domain at it, that gets into DNS (the Domain Name System; literally how domains are mapped to IPs so humans don’t have to remember them). Cloudflare has guides for this.

Since it’s your home IP, it might change. Either be fine changing your DNS if your IP changes (which usually isn’t often if you have a decent connection), or look into something called “dynamic DNS” (just a thing that grabs your current IP and updates your domain to point at it).

NOW you can start getting into things like SSL. Remember that SSL doesn’t protect you from some guy trying to hack your site/server, it just makes it harder for them to view or change content while it’s being sent from the server to a site visitor (or back again, if you have a form).

Google “add SSL to Apache”, you’ll find references to “VirtualHost” and a bunch of config lines starting with “SSLCertificate…”. You’ll also find plenty of references to “LetsEncrypt” (a free SSL provider) and “Certbot” (a program that lets you generate the certificates with LetsEncrypt). Follow those.

As above with port 80, you’ll need to make sure that port 443 (the https port) is allowed for your server through your router. Again, block your server from connecting to the rest of your network. The Internet can touch it, someone will try to hack it. The SSL doesn’t save you from this.

As for reverse proxies, you don’t need one unless you’re getting into load balancing or header manipulation (which means you’ll probably never need one for this project).

I’m happy to answer follow-up questions.

I just started my mbin instance a week or two ago. When I did, I wrote a guided install script (it’s a long story, but I ended up having to blow away the server like 7 times and re-install).

This might be overkill for your purposes, but it’s the kind of thing I have in mind.

Note1: Sorry, it’s kinda sloppy. I need to clean it up before I submit a PR to the mbin devs for possible inclusion in their documentation. Note2: It assumes that you’re running a single-user instance, and on a single, small server, with no external requirements.

https://alexanderesmith.com/mbin/install_mbin.bash

My profesional experience is in systems administration, cloud architecture, and automation, with considerations for corporate disaster recovery and regular 3rd party audits.

The short answer to all of your questions boil down to two things;

1: If you’re going to maintain a system, write a script to build it, then use the script (I’ll expand this below).

2: Expect a catastrophic failure. Total loss, server gone. As such; backup all unique or user-generated data regularly, and practice restoring it.

Okay back to #1; I prefer shell scripts (pick your favorite shell, doesn’t matter which), because there are basically zero requirements. Your system will have your preferred shell installed within minutes of existing, there is no possibility that it won’t. But why shell? Because then you don’t need docker, or python, or a specific version of a specifc module/plugin/library/etc.

So okay, we’re gonna write a script. “I should install by hand as I’m taking down notes” right? Hell, “I can write the script as I’m manually installing”, “why can’t that be my notes?”. All totally valid, I do that too. But don’t use the manually installed one and call it done. Set the server on fire, make a new one, run the script. If everything works, you didn’t forget that “oh right, this thing real quick” requirement. You know your script will bring you from blank OS to working server.

Once you have those, the worst case scenario is “shit, it’s gone… build new server, run script, restore backup”. The penalty for critical loss of infrastructure is some downtime. If you want to avoid that, see if you can install the app on two servers, the DB on another two (with replication), and set up a cluster. Worst case (say the whole region is deleted) is the same; make new server, run script, restore backups.

If you really want to get into docker or etc after that, there’s no blocker. You know how the build the system “bare metal”, all that’s left is describing it to docker. Or cloudformation, terraform, etc, etc, etc. I highly recommend doing it with shell first, because A: You learn a lot about the system and B: you’re ready to troubleshoot it (if you want to figure out why it failed and try to mitigate it before it happens again, rather than just hitting “reset” every time).

heh, pulling out

This is fucked.

I worked in call centers for many years (technical support and sales). I need to hear the customer’s tone; ecstatic, livid, and everything in between. I sit on the other end, shut my mouth, and listen to the whole rant, then calmly offer suggestions. Do they scream some more? Maybe. Do I need to take it personally? Of course not.

It drives me fucking crazy when some dipshit customer service rep hears one swear word (not even directed at them, like “I hate this fuckin’ thing”, not “you’re a fuckin’ dumbass”) and start in on the “if you keep swearing at me, I’ll end the call”. Grow up, you work in a service industry, and your company probably fucked up.

My favorite calls were the ones where someone called to cancel and tore up their voice yelling about all the reasons our product was gabrage. Very, very roughly, about 15% of the time there was nothing I could do (even if I fixed the problem, they have lost faith and will get their money back, or sue trying, so I just refund and move on). Another 25% was me fixing the problem and offering a credit because we fucked up. About half the time, its something stupid and simple and they get their problem solved, and the rest of the time was some absolutely crazy broken shit that makes me work with someone two tiers above me for a few hours fixing it (for everyone, not just that caller), then the customer is so happy they renew everything for a year because they know they’re gonna get great support.

I loved those calls. They were the reason I kept showing up to work. I learned a ton in those jobs, and my favorite thing was hearing someone go from completely apoplectic to surprised and elated that everything was fixed.