• 0 Posts
  • 16 Comments
Joined 5 months ago
cake
Cake day: June 11th, 2024

help-circle










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





  • 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).