• 1 Post
  • 7 Comments
Joined 3 years ago
cake
Cake day: June 26th, 2023

help-circle
  • Absolutely! To be honest, I don’t even want to have countless machines under my umbrella, and constantly have consodilation in mind - but right now, each machine fulfills a separate purpose and feels justified in itself (homelab for large data, main VPS for anything thats operation critical and cant afford power/network outages and so on). So unless I find another purpose that none of the current machines can serve, I’ll probably scale vertically instead of horizontally (is that even how you use that expression?)


  • In addition to the other commenter and their great points, here’s some more things I like:

    • ressource efficient: im running all my stuff on low end servers, and cant afford my reverse proxy to waste gigabytes of RAM (kooking at you, NPM)
    • very easy syntax: the Caddyfile uses a very simple, easy to remember syntax. And the documentation is very precise and quickly tells me what to do to achieve something. I tried traefik and couldn’t handle the long, complicated tag names required to set anything up.
    • plugin ecosystem: caddy is written in go, and very easy to extend. There’s tons of plugins for different functionalities, that are (mostly) well documented and easy to use. Building a custom caddy executable takes one command.


  • If you’re referring to the “LabProxy VPS”: So that I don’t have to point a public domain that I (plan to) use more and more in online spaces to my personal IP address, allowing anyone and everyone to pinpoint my location. Also, I really don’t want to mess with the intricacies of DynDNS. This solution is safer and more reliable than DynDNS and open ports on my router thats not at all equipped to fend off cyberspace attacks.

    If you’re referring to the caddy reverse proxy on the LabProxy VPS: I’m pointing domains that I want to funnel into my homelab at the external IP of the proxy VPS. The caddy server on that VPS reads these requests and reverse-proxies them onto the caddy-port from the homelab, using the hostname of my homelab inside my tailscale network. That’s how I make use of the tunnel. This also allows me to send the crowdsec ban decisions from the homelab to the Proxy VPS, which then denies all incoming requests from that source IP before they ever hit my homelab. Clean and Safe!


  • Hey! I’m also running my homelab on unraid! :D

    The reverse proxy basically allows you to open only one port on your machine for generic web traffic, instead of opening (and exposing) a port for each app individually. You then address each app by a certain hostname / Domain path, so either something like movies.myhomelab.com or myhomelab.com/movies.

    The issue is that you’ll have to point your domain directly at your home IP. Which then means that whenever you share a link to an app on your homelab, you also indirectly leak your home location (to the degree that IP location allows). Which I simply do not feel comfortable with. The easy solution is running the traffic through Cloudflare (this can be set up in 15 minutes), but they impose traffic restrictions on free plans, so it’s out of the question for media or cloud apps.

    That’s what my proxy VPS is for. Basically cloudflare tunnels rebuilt. An encrypted, direct tunnel between my homelab and a remote server in a datacenter, meaning I expose no port at home, and visitors connect to that datacenter IP instead of my home one. There is also no one in between my two servers, so I don’t give up any privacy. Comes with near zero bandwith loss in both directions too! And it requires near zero computational power, so it’s all running on a machine costing me 3,50 a month.




  • I’ve done this a couple of times, and let me tell you, it’s a journey.

    General info

    when I did this, I stored all my games on a generic drive that I wanted to easily access from both windows and Linux. Lutris / Wine would usually expect every game to sit in its own prefix, but since every prefix uses multiple hundreds of MB and makes folder structures annoying to navigate, I instead opted to use my default prefix (~/.wine) for literally everything. While this probably has downsides, it worked for me most of the time.

    In this default prefix, through the wineconfig, I added my data drive as an additional D: mount to make Installation paths identical to how they’d be on windows, even if it doesn’t really matter. I also mounted library folders like “Documents” to the same folder Windows would access to (hopefully) use the same save files between Windows and Linux. For games saving to AppData, I had to create manual links from the main folder on the data drive into the AppData folder in the wine prefix.

    Installing Games

    I’ll assume you’re either getting clean steam files from “the forum” or using repacks that need installing. In the latter case, I’d usually not bother adding the installer to lutris, it seemed more effort than needed. I’d rather open the terminal, navigate to ~/.wine, put the installer .exe in the same folder, and run something along the lines of WINEPREFIX=$(pwd) installer.exe. Specifying the prefix made sure that no new prefix would be created. Obviously you can also run the same command anywhere else on the filesystem, just remember to actually specify the prefix you want to use.

    At that point, the installer should hopefully open. Proceed like usual and specify the installation path (in my case something like “D:/Games/Name of Game” or whatever). Best case scenario, everything works. Worst case, something breaks or fails, at which point id just boot into a windows install I had on the side, installed there, then booted back to Linux. You could probably achieve the same with a vm, but I never tested that.

    Running games

    Once you’ve survived the installation, you can add the game to your lutris library. Remember to set the wine prefix to the default one. You’ll also want to mess around with different runners (“wine” basically never, “lutris-wine” sometimes, “proton” or “proton-ge” for steam games, and there’s plenty more) and environment variables (enabling DXVK and DXVK_ASYNC for performance and other stuff). Since every game is totally different and requires different flags, I skipped all tinkering and went straight to https://www.protondb.com/, where you can look up the game and the additional info other people use on the game. Transfer that info into your lutris game settings, and then hopefully things work.

    What if they don’t

    Oh man, this happened a lot. Let me preface that I was on arch, so my troubles might not apply to you. When games don’t launch, you can right click the game in lutris and look into the wine logs, where you’ll most often find some form of error. Sometimes it’s file access permissions (save location read only, game exe not executable, or whatever else), wrong or missing environment variables, or (for me this was the most frequent) problems with some media decoding component of the system that simply couldn’t decode the media files no matter how many additional codec packages I installed.

    At some point I just gave up and went back to windows. Gaming on Linux is a fucking handful and, for someone with a full time job and at most 2-3 hours of game time per day, spending 2 thirds of that trying to get shit to run wasn’t a good investment of my time once the novelty of “wow I’m doing such cool and nerdy stuff” wore off. So I’m hoping this helps you and your experience will be better than mine.

    I didn’t proof read this, so no guarantee for perfect grammar or content. In addition, some helpful subreddits are /r/LinuxCrackSupport, /r/CrackSupport/ and to an extent /r/linux_gaming/. You can find some limited degree of help and information there too.

    Let me know if you have further questions.

    Edit: corrected helpful subreddits