hamsda

It depends on what it is. I do not have a singular documentation-platform or wiki for those things. I'm more of the keep the docs where the code is guy. I also try to keep complexity to a minimum.

All my linux server setups are done with ansible. ansible itself is pretty self-documenting, as you more or less declare the desired outcome in YAML form and ansible does the rest. This way, I do not need to remember it, but it's easier to understand when looking it up again.

Most of my projects have a git repository, so most of what I need to know or do is documented

• in a README.md
• as pipeline-instructions inside .gitlab-ci.yml

This way, I was able to reduce complexity and unify my homelab projects.

My current homelab-state is:

• most projects are now docker-based
• most projects have a GitLab CI for automated updating to newer versions
• the CI itself is a project and all my CI-docker-based deploys use this unified pipeline-project
• most projects can be tested locally before rolling out new versions to my VMs
• some projects have a production and a staging server to test
• those which cannot be dockerized or turned into a CI are tools and don't need that (e.g. ansible playbooks or my GitLab CI)

On what to include, I always try to think: Will I still be able to understand this without documentation if I forget about the project for 6 months and need to make a change then? If you can't be sure, put it in writing.

If it's just a small thing regarding not the project itself or the functionality or setup itself but rather something like I had to use this strange code-block here because of XXX, I'll just put a comment next to the code-line or code-block in question. These comments mostly also include a link to a bug-report if I found one, so i can later check and see if it's been fixed already.

Before I got more into selfhosting, I was running nothing but syncthing in a Raspberry Pi.

The pi was the "Server" and all the other Clients were only connected to the pi (in syncthing).

Worked flawlessly :)

Ha, I wish I could.

I'm not 100% satisfied, so I'm still searching for the "perfect distro for me", if it even exists.

I have been using Arch Linux on my personal PC and company laptop for 4 years, but I couldn't get some things to work. Things that, after installing Fedora, worked out of the box.

My current setup is:

• EndeavourOS (e.g. arch linux with a GUI-installer) for my PC at home
• Fedora Workstation 43 for my company laptop
• Servers are all running Debian, I'll probably never change that
• Hypervisor for VMs is Proxmox VE, which is Debian too

Currently using nginx-proxy-manager for exactly this purpose. Nice and easy-to-use UI, including automatic LetsEncrypt ssl certificates :)

I'm using CheckMK to monitor my hypervisor, physical hardware like disks, CPU etc. and SNMP-capable hardware like my pfSense firewall via a CheckMK instance in docker. It either works in docker or on a few different linux based OS like ubuntu and debian (see CheckMK download page).

There's a free and open source version (called raw edition, GitHub Link) which I am using. It comes with a lot of checks / plugins for monitoring stuff out of the box and if there's something it doesn't ship, you can easily create your own check in whatever language your server is capable of executing a binary of. Or you could look up if there's a user-contributed plugin on the official CheckMK Exchange Platform.

The whole configuration of this is based on rules with a lot of predefined rules and sane defaults already set.

To have an example for your use-case: You can monitor docker-logfiles and let CheckMK warn you, if specific keywords are or are not in a logfile. You will then be able to view the offending lines in the monitoring UI.

Why do I use this?

• We use it at work
• FOSS
• docker makes updating this easy
• can send mails, teams notifications, ...
• very customizable and expandable

my docker compose file

# docker-compose.yml

services:
  monitoring:
    image: checkmk/check-mk-raw:2.4.0-latest
    container_name: monitoring
    restart: unless-stopped
    environment:
      - CMK_PASSWORD=changeme
    ports:
      # WEB UI port
      - "5000:5000"
      # agent communication port
      - "8000:8000"
      # used for SNMP
      - "162:162/udp"
      - "514:514/tcp"
      - "514:514/udp"
    volumes:
      - "./monitoring:/omd/sites"
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env

I was just visiting a friend of mine last sunday with my SteamDeck and we played Unrailed! the whole day :D

The SteamDeck is THE perfect, portable fun-games-machine to just take with you. And every sale there's another few local-splitscreen-multiplayer games on sale, my library is scared already.

If you did not live through the time of "going to your friends to play games", this is your ticket to a past you sadly never got to experience.

Haha, same here.

Though for me it wasn't about the Zerg, I just liked the logo. That's how I got to Arch and that's (partly) why my servers use debian :D

Oh, that looks really good. I guess I'll add that to my Phone-Wallpaper-Collection, thank you very much :)

If you're selfhosting, the cloud is your someone else's computer ;)

I didn't mean to get caught up in exceptions or exaggerations. I'm no developer either, so I have zero background-knowledge about game-development or game-engines.

Though as I work in IT (again, no developer) and live within a zero-IT-knowledge friend circle, I tend to try and shine a little light on some things that, to the outside, might seem simple but maybe aren't. I guess sometimes I'm trying to err on the side of caution a little too much.

I definitely think there are a few of those one-line, true/false settings that could just be toggled, especially things that are handled by the engine instead of the game-logic itself, though I cannot speak of experience here.

I'm talking about ones that are like one line of code being set to true instead of false etc

I don't know how many, if any, settings matching the true/false + 1 line of code restraints even exist.

If you can change a setting, even if it's a binary choice, someone had to think about, implement and test everything pertaining to these choices.

Depending on what kind of mechanic we're talking about and how deeply integrated into the rest of the game this mechanic is, that could be a big task.

I did not run OPNSense, but I have a direct comparison for pfSense as VM on Proxmox VE vs pfSense on a ~400€ official pfSense physical appliance.

I do not feel any internet-speed or LAN-speed differences in the 2 setups, I did not measure it though. The change VM -> physical appliance was not planned.

Running a VM-firewall just got tiring fast, as I realized that Proxmox VE needs a lot more reboot-updates than pfsense does. And every time you reboot your pfSense-VM-Hypervisor, your internet's gone for a short time. Yes, you're not forced to reboot. I like to do it anyway, if it's been advised by the people creating the software I use.

Though I gotta say, the pfSense webinterface is actually really snappy and fast when running on an x86 VM. Now that I have a Netgate 2100 physical pfSense appliance, the webinterface takes a looooong time to respond in comparison.

I guess the most important thing is to test it for yourself and to always keep an easy migration-path open, like exporting firewall-settings to a file so you can migrate easily, if the need arises.

[EDIT] - Like others, I also would advice heavily against using the the same hypervisor for your firewall and other VMs. Bare-Metal is the most "uncomplicated" in terms of extra workload just to have your firewall up and running, but if you want to virtualize your firewall, put that VM on its own hypervisor.