Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
It sounds like maybe you're looking for a primer on how networking works across the internet? If so, here's a few concepts to get you started (yeah unfortunately this huge post is JUST an overview), and note that every one of these services can also be self-hosted if you really want to learn the nuts & bolts...
DNS is the backbone of everything, it is the service that converts names like "lemmy.world" into an actual IP address. Think of it like the phone book of the internet, so like if you wanted to call your favorite pizza place you would find their name, and that would give you their phone number. Normally any domain that you try to reach has a fixed (or static) IP address which never (or rarely) changes, and when you register your domain you will point it to a DNS server that you have given authoritative access to provide the IP where your server can be found.
But what if you're running a small setup at home and you don't actually have a static IP for your server? Then you look to DDNS (Dynamic DNS) and point your domain's DNS to them. There are several free ones available online you can use. The idea is you run a script on your server that they provide, and every time your IP from your ISP changes, the script notifies the DDNS service, they update their local DNS records so the next person looking for your domain receives the updated IP. There can be a little delay (up to a few minutes but usually only seconds) in finding the new address when your IP changes, but otherwise it will work very smoothly.
You mentioned DHCP, so here's a quick summary of that. Basically you are going to have a small network at your home. Think of your internet router as the front-end, and everything behind it like you computers or mobile devices are going to be on their own little private network. You will typically find they all get an IP address starting with 192.168.* which is one or the reserved spaces which cannot be reached from the internet except by the rules your router allows. This is where DHCP comes in... when you connect a device it sends out a broadcast asking for a local network IP address that it is allowed to use. The DHCP server keeps track of the addresses already in use, and tells your device one that is free. It will also provide a few other local details, like what DNS server to use (so if you run your own you can tell the DHCP service to use your local server instead of talking to your ISP). So like the phone book analogy, your DHCP service tells all of your local devices what phone number they are allowed to use. other Now to put all of this together, you probably have a router from your ISP. That router has been pre-programmed with the DHCP service and what DNS servers to use (which your ISP runs). The router also acts like the phone company switchboard... if it sees traffic between your local devices like a computer trying to reach your web server, it routes those calls accordingly. If you are trying to get to google then the route sends your call to the ISP, whose routers then send your connection to other routers, until it finally reaches google's servers. Basically each router becomes a stepping stone between your IP address and someone else's IP address, bringing traffic in both directions.
OK so now you want to run a web server for your domain. This means that besides getting the DNS routing in place, you also need to tell your router that incoming web traffic needs to be directed to your web server. Now you need to learn port numbers. Web pages traffic on port 80, and SSL pages use port 443. Every type of service has its own port number, so DNS is port 53, ftp is port 21, and so on. Your router will have a feature called port-forwarding. This is used when you always want to send a specific port to a specific device, so you tell it that any incoming traffic on port 80 needs to be sent to the IP address of your web server (don't worry, this won't interfere with your own attempts to reach outside websites, it only affects connections that are trying to reach you).
Now if you've followed along you might have realized that even on your local network, DHCP means that your server's own IP address can change, so how can you port-forward port 80 traffic to your web server all the time? Well you need to set a local static IP on your server. How that is done will be specific to each linux distribution but you can easily find that info online. However you need to know what addresses are safe to use. Log in to your router, and find the DHCP settings. In there you will also see a usable range (such as 192.168.0.100 to 192.168.0.199). You are limited to only changing the last number in that set, and the router itself probably uses something like 192.168.0.1. Each part of an address is a number between 0-255 (but 0 and 255 are reserved, so except in special cases you only want to use the numbers 1-254), so with my example of the address range being used by DHCP, this means that you would be free to use any address ending in 200-254. You could set the static IP of your web server to 192.168.0.200, and then point the port-forwarding to that address.
Now remember, your local IP address (the 192.168 numbers) are not the same as your external internet address. If you pay your provider for a static internet address, then your router would be programmed with that number, but your web server would still have its local address. Otherwise if you're using DDNS then you would tell that service the outside IP address that your router was given by your ISP (who coincidentally is running a DHCP that gave your router that address).
Let me see if I can diagram this... OK so imagine your router has the internet address of 1.2.3.4, your web server has the local address of 192.168.0.200, and someone from the internet who has address 100.1.1.1 is trying to reach you. The path would be something like this:
100.1.1.1 -> (more routers along the way) -> your ISP -> 1.2.3.4 (router) -> 192.168.0.200 (server)
They send a request to get a web page from your server, and your server send the page back along the same path.
Yes there's a lot to it, but if you break it down one step at a time you can think of each step as an individual router that looks to see if the traffic going to something on the outside or going to something on the inside. Which direction do I need to send this along? And eventually the traffic gets to a local network that says "hey I recognize this address and it needs to go over to this device here." And the key to all of this routing is DNS which provides hints on where to forward the information to the next router in the path. I can break things down further for you if something isn't clear but hopefully that gives you a broad overview on how things move around on the internet.
Holy shit dude, that was actually very helpful! I'll need a few more go-throughs to fully grasp every piece here, but thanks a ton for writing it so precisely.
Based on this though, is there no way to have port-forwarding except setting it up explicitly in my router? I ask this because 1) in my personal setup, I'll be switching between wifi and mobile data quite often, and 2) I may end up on an institutional wifi after some time, in which case I won't have access to the router
Correct. What you'd need in that case is a reverse proxy like ngrok, which is a bit more difficult to set up.