Dran

Fail2ban and containers can be tricky, because under the hood, you’ll often have container policies automatically inserting themselves above host policies in iptables. The docker documentation has a good write-up on how to solve it for their implementation

https://docs.docker.com/engine/network/packet-filtering-firewalls/

For your usecase specifically: If you’re using VMs only, you could run it within any VM that is exposing traffic, but for containers you’ll have to run fail2ban on the host itself. I’m not sure how LXC handles this, but I assume it’s probably similar to docker.

The simplest solution would be to just put something between your hypervisor and the Internet physically (a raspberry-pi-based firewall, etc)

+1 for cmk. Been using it at work for an entire data center + thousands of endpoints and I also use it for my 3 server homelab. It scales beautifully at any size.

Are you maybe thinking of https://distr1.org/ made by the i3 guy?

Generally the lifecycle with this sort of thing is old_thing becomes an alias to new_thing, and eventually old_thing gets dropped as an alias down the line.

It’s still decent advice to learn dnf native calls and to update scripts using yum to those native calls.

I’m a big fan of tiling window managers like i3 or awesome (awesome wm). Awesome is the one I use. It’s tiling and the entire interface is built from scripts that they encourage you to modify. Steep learning curve but once you get it how you like, there’s nothing like it.

That is usually more incompetence than malice. They write a game that requires different operation on amd vs Nvidia devices and basically write an

If Nvidia: Do x; Else if amd: Do Y; Else: Crash;

The idea being that if the check for amd/Nvidia fails, there must be an issue with the check function. The developers didn’t consider the possibility of a non amd/Nvidia card. This was especially true of old games. There are a lot of 1990s-2000s titles that won’t run on modern cards or modern windows because the developers didn’t program a failure mode of “just try it”

You would expose a single port to multiple vlans, and then bind multiple addresses to that single physical connected interface. Each service would then bind itself to the appropriate address, rather than “*”

You should consider reversing the roles. There’s no reason your homelab cannot be the client, and have your vps be the server. Once the wireguard virtual network exists, network traffic doesn’t really care which was the client and which was the server. Saves you from opening a port to attackers on your home network.

Sorry I should have said “carbons and carbons related qol extensions”

Did you ever get carbons working properly? (As in, mobile and desktop clients of the same user both getting messages and marking as read remotely between them)

*privacy from everyone except us, which conveniently makes our ad revenue line go up.

There are also full-suites like rancher which will abstract away a lot of the complexity

How has nobody in this thread said check_mk yet?

It’s free, you host it yourself. It’s built off of nagios, compatible with nagios plugins, supports snmp or agent based checks. It can email, SMS, slack or discord you when something breaks, you can write your own custom checks in any language that can output to a local console… I could never imagine even looking for something else.

I certainly wasn’t just born good at this. Unironically if you want to learn how something works, try to automate it. By the time it’s automated you’ll understand basically every part of it at at least a basic high-level.

has xmpp figured out carbons yet between multiple clients? also are there any good mobile clients?

If one doesn’t exist, it would seem to be a fairly straightforward (if not a smidge tedious) thing to implement. Ever thought about learning web development?

That’s a good word. I always love learning new words. Thank you!

It’s like they think V for Vendetta was a blueprint for how to run a utopia.

I have condensed almost all of my workflows into pure bash scripts that will run on anything from bare metal to a vm to a docker container (to set up and/or run an environment). My dockerfiles mostly just run bash scripts to set up environments, and then run functions within the same bash scripts to do whatever things they need to do. That process is automated by the bash scripts that built my main host. For the very few workflows I have that aren’t quite as appropriate for straight docker (wireguard for example) I use libvirt to automate building and running virtual machines as if they were ephemeral containers. Once the abstraction between container and vm is standardized in bash, the automation doesn’t really need to care which is which, it just calls start/stop functions that change based on what the underlying tech is. Because of that, I can have the canary system build and run containers/vms in a sandbox, run unit tests, and return whether or not they passed. It does that via cron once a week and then supplants all the running containers with the canary versions once unit tests pass.

Basically I got sick of reinventing the wheel every time a new technology came out and eventually boiled everything down into bash so that it’ll run on anything it needs to. Maybe podman in userland becomes the new hotness next year, or maybe I run a full fat k8s like I do at work. Pure bash lets me have control over everything, see how everything goes together, and make minor modifications to accommodate anything I need it to.

It sounds more complicated than it really is, It took me like a week of evenings to write and it’s worked flawlessly for almost a year now. I also really really really hate clicking things by hand lol, so I automate anything I can. Since switching off proxmox, this is the first environment that I have entirely automated from bare-metal to fully running in a single command.

I’m incredibly lazy; it’s one of my best qualities.

Virtual machines also exist. I once got bit by a proxmox upgrade, so I built a proxmox vm on that proxmox host, mirroring my physical setup, that ran a debian vm inside of the paravirtualized proxmox instance. They were set to canary upgrade a day before my bare-metal host. If the canary debian vm didn’t ping back to my update script, the script would exit and email me letting me know that something was about to break in the real upgrade process. Since then, even though I’m no longer using proxmox, basically all my infrastructure mirrors the same philosophy. All of my containers/pods/workflows canary build and test themselves before upgrading the real ones I use in my homelab “production”. You don’t always need a second physical copy of hardware to have an appropriate testing/canary system.