FrederikNJS

Dunno… Lack of collaboration skills in a Linux distro seems a lot like incompetence to me…

Ubuntu -> Debian -> Linux Mint -> Fedora -> Arch -> Manjaro -> EndeavourOS -> SuSE Linux -> NixOS

I’m pretty happy on NixOS now…

@eddiereasoner@lemmus.org might actually be on to something…

Depending on the wall switch you have, you might be able to add a spring that makes it always return to the previous position when released. At least the switches I have in my house have a special little socket for adding a spring.

So in your Zigbee control panel you would configure the “power on behaviour” of the smart light/socket to “toggle”.

Then I you would add the spring inside your physical switch.

Now when you press the switch it would cut the power to the light/socket briefly, and as soon as you release the switch the power would be restored.

If the light/socket is on, you press and release the switch, which cuts the power and the light/socket stays off due to the “toggle” behaviour.

If the light/socket is off, the light/socket is still powered, soo you can still turn it on via Zigbee, and if you pres the switch, it momentarily cuts the power and the toggle behaviour would now make if turn on.

This gives you basically the same behaviour as if you installed a relay, but if you use smart bulbs you gain the benefit of being able to control the brightness, color temperature, and hue, if it has those controls

Sonoff makes a bunch of Zigbee smart relays, that can take input from a normal switch.

It’s basically just a Zigbee relay that can connect and disconnect regular wires, just like a switch does. But it also has terminals for connecting a regular switch, which then just functions as a button that controls the relay.

Something like this: https://sonoff.tech/en-eu/products/sonoff-zbmini-extreme-zigbee-smart-switch-zbminir2

Does this image not work anymore?

https://docs.linuxserver.io/images/docker-unifi-network-application/

While PETG certainly has a lot more moisture problems than PLA, PLA can still give you a lot of grief if it isn’t dry enough. Stringing, oozing, uneven extrusion, and many other weird problems. I would definitely try to dry the filament…

But this could also look a bit like over/under-extrusion… Have you tried calibrating your e-steps?

The containers in my setup are running in a Kubernetes cluster. My Kubernetes cluster consists of 3 physical servers (one old desktop computer and 2 Intel NUCs).

On that cluster I run many different things, Jellyfin, Plex, *arr-stack, downloader, Immich, zigbee2mqtt, home-assistant, audiobookshelf, calibre-web, Forgejo, ArgoCD, Homebox, Paperless, Factorio servers, Velero, and a bunch of other stuff.

Because I run so many different things on the same 3 physical machines, using containers, then there’s no way to split this into VLANs.

I could make a “kubernetes” VLAN, but everything else on my network would need to be connected with it anyway. All my computers, phones and TVs need to access Kubernetes (Jellyfin), and Kubernetes need to access everything else such as EV charger, heat pump, and the power monitoring in my power meter. Therefore I need to control my networking at a different level.

Yes, that does indeed sound like you have all the stuff necessary to make this work.

In my home network this wouldn’t work, as I’m running all my stuff in containers on multi-purpose servers, and therefore I can’t really split things per VLAN. Most other people in the homelab/self host community also use their servers for multiple purposes at the same time, so VLANs alone often doesn’t cut it.

That depends a lot on what you do with them…

VLANs work on a layer where devices can either reach each other or they cannot.

Let’s say you have your main desktop computer in the “main” VLAN, and your Jellyfin server in the “jellyfin” VLAN, and a third server for your home-assistant in the “home-assistant” VLAN, and finally some IOT devices in the “iot” VLAN.

You connect the VLANs as follows:

• “main” can reach the Internet, but you also want to access your jellyfin and home-assistant, so you connect it to those two VLANs (“jellyfin” and “home-assistant”)
• “Jellyfin” can reach the Internet (because you want updates), but Jellyfin doesn’t need to reach anything else on your local network… However since you already connected “main”, then “jellyfin” can reach it.
• “home-assistant” needs to reach the Internet, but also the “iot” VLAN where some of the devices it controls resides. You also already connected “main” because you wanted to access home-assistant from your computer.
• “iot” is blocked from reaching the internet, and it’s only connected to the “home-assistant” VLAN because home-assistant needs to reach it.

Remember that all connected VLANs much be bidirectional.

Now someone compromises your Jellyfin. They now control and has access to everything on the Jellyfin server, but they also have network reachability to your main computer, because your “main” and “home-assistant” VLANs are connected. They can now try to exploit your main computer.

If they are successful in exploiting your main computer, then they can use your main computer to jump to the home-assistant server because again, these two VLANs are connected. And you likely have the credentials for accessing home-assistant available on your main computer somewhere.

Now they are on your home-assistant server, and they can now start trying to exploit your IOT devices.

If VLANs are connected, they don’t care which direction the traffic flows.

If you want to control traffic flow directions you need a firewall. A firewall can sit between VLANs and block traffic coming from one to other, but not the other to the one.

If Jellyfin gets compromised, you risk everything else on the same server getting compromised, as well as everything that server can reach.

VLANs can certainly reduce what is at risk, but wouldn’t the machine running the Jellyfin client be reachable from the Jellyfin server? And if they manage to move laterally to the client machine, what could they then reach from there?

Sure… If someone managed to stream some of my media… They probably earned it… But then they exploit a vulnerability to perform arbitrary code execution, and leverage that to hack everything else on my network…

https://app.opencve.io/cve/CVE-2023-30626

Or in some cases ONLY allowing them to reach the Internet. So they can’t access your other devices…

In that case Debian, Ubuntu, and Windows server should absolutely dwarf OSX…

That said, I personally wouldn’t consider “server use” to be “mainstream”… To me install-base does not equate to “mainstream”.

Shouldn’t Ubuntu be more “mainstream” than debian?

https://docs.renovatebot.com/

All my docker images are in code in Github.

Renovate makes a PR when there are image or helm chart updates.

ArgoCD sees the PR merge and applies to Kubernetes.

For a few special cases I use ArgoCD-image-updater.

I have my Firefox configured to force HTTPS, so it’s rather inconvenient to work with any non-HTTPS sites.

Because of that I decided to make my own CA. But since I’m running in Kubernetes and using cert-manager for certs, this was really easy. Add a resource for a self-singed issuer, issue a CA cert, then create an issuer based on that CA cert. 3 Kubernetes resources total: https://cert-manager.io/docs/configuration/ca/ and finally import the CA cert on your various devices.

However this can also be done using LetsEncrypt, with the DNS01 challenge. That way you don’t need to expose anything to the Internet, and you don’t need to import a CA on all of your devices. Any cert you issue will however appear in certificate transparency logs. So if you don’t want anyone to know that you are running a Sonarr instance, you shouldn’t issue a certificate with that in it’s name. A way around that is a wildcard cert. Which you can then apply to all your subservices without exposing the individual service in logs. The wildcard will still be visible in the logs though…

In addition people often use VLANs for security segregation. For example you might buy a bunch of cheap Chinese security cameras, but want to ensure that they can’t send anything back to the manufacturer. Then you can make a VLAN with no Internet access for the cameras.