farcaller

I went for a much simpler approach lately as I downscaled my hardware for efficiency.

I run NixOS on the bare metal. It gives the system management a declarative approach, just like kubernetes would. On top of that, I run libvirt as a hypervisor. In other scenarios I'd use tinyvmm and cloud-hypervisor, but I found qemu way better for the variety of homelab workloads and libvirt is pretty straightforward.

Some vms have pci passthrough, e.g. my routeros vm gets a bunch of NICs directly, some have various funny network topology. Libvirt used to be a pain in that regard, but it's actually fine with NixOS because you manage both sides of the networking stack in declarative configuration.

I run NixOS on the vms too (now for the sake of easy upgrades), and I have a bit of a split between running services natively (systemd is very good about “containerizing” things nowadays) and using docker (mostly because of laziness, e.g. Elastiflow was easier to deploy this way). Finally, I have a single dokerized Ubuntu that's more like a VM (as in, I never had a dockerfile for it, it's fully stateful) running the matter home automaton bits because I gave up on properly containing the matter python stack and went for an easy way out.

Now, a word about alternatives.

I used to run Ubuntu. No more. Upgrading the OS is always a huge pain even if everything is in docker. I want my OS to be managed in a config file and be able to easily roll back to the previous state. I used to run k3s, but even though it is much thinner than k8s, it is still very much ram hungry and I just don’t want to pay for that. Besides, complex networking is often non-trivial due to how its networking works, and multus is a world of pain. I used to run different hypervisors for the VMs (kubevirt, tinyvmm, a bunch others). I went way back to libvirt mostly because it’s straightforward in tuning very specific qemu bits I cared for in the homelab. I have some cpu overprovisioning, so I want to make my quotas set up extremely precisely, sacrificing the right workloads.

I’ll make a note here that a firewall is useful for internal traffic, too. Those IoT devices can get pretty annoying, so you'd want to e.g. drop your cheap webcams into a VLAN and disallow them from talking to enjoying but their cloud, and especially the other VLANs, or isolate Alexa capable device so it won’t try to figure what else you got there in your house over mDNS (it will).

A managed switch would do nicely. Having isolated ports on the switch (and the wifi AP) is also great if you want to make sure the specific device will only talk to the gateway and not its peers.

Here's how it works: unifi devices need to communicate with the controller over tcp/8080 to maintain their provisioned state. By default, the controller adopts the device with http://controller-ip:8080/inform, which means that if you ever change the controller IP, you’ll must adopt your devices again.

There are several other ways to adopt the device, most notably using the DHCP option 43 and using DNS. Of those, setting up DNS is generally easier. You'd provision the DNS to point at your controller and then update the inform address on all your devices (including the USG).

Now, there's still a problem of keeping your controller IP and DNS address in sync. Unifi, generally, doesn’t do DNS names for its DHCP leases, and devices can’t use mDNS, so you’ll have to figure a solution for that. Or, you can just cut it short and make sure the controller has a static IP―not a static DHCP lease, but literally, a static address. It allows your controller to function autonomously from USG, as long as your devices don’t reach to it across VLANs.

Unifi is specific about expecting the controller address to not change. You have several options: There's the “override controller address” setting, which you can use to point the devices at a dns name, instead of an ip address. The dns can then track your controller. It doesn’t exactly solve your issue, though, as USG doesn’t assign dns names to dynamic allocations.

Another option is to give the controller a static IP allocation. This way, in case you reboot everything, USG will come up with the latest good config, then will (eventually) allocate the IP for controller, and adopt itself.

Finally, the most bulletproof option is to just have a static IP address on the controller. It's a special case, so it's reasonable to do so. Just like you can only send NetFlow to a specific address and have to keep your collector in one place, basically.

I'd advise against moving dhcp and dns off unifi unless you have a better reason to do so, because then you lose a good chunk of what unifi provides in terms of the network management. USG is surprisingly robust in that regard (unlike UDMs), and can even run a nextdns forwarding resolver locally.

However, XAMPP didn’t just die because it opened itself up to Microsoft and got extinguished

So, we went from the somewhat imaginary “google killed xmpp” to fully fictional “Microsoft killed xampp” now? it's almost like the fedipact people literally have no clue what they are talking about.

I took a look at the current traffic and you’re absolutely correct, lemmy (as of 0.19) has a proper schema with everything covered!

But lemmy doesn’t use “plain json”, it annotates some fields with the schema, just not all of them, which makes it a mess. You either do json-ld proper, or you don’t do it at all.

no Federation with instances that use altered versions or proprietary versions of AP.

It's especially funny given (the last time I checked) neither kbin nor lemmy actually followed the spec properly. They ignore the jsonld requirements and resort to field names, that, by the spec, should be dropped.

Edit: lemmy is actually good now!

isn’t threads already several times larger than the whole of the “fediverse”?