The thing that really helped me was using my philips hue bulbs with my zigbee device directly instead of through the hue hub. That made the mesh network extend to the entire house instantly, because the lights have constant power and act as repeaters automatically.
I'm using an Electrolama zzh with an extension cord and it works perfectly, because there's essentially 1-4 repeaters in every room.
You're welcome. It has some really nice side-effects - i.e. if I want to quickly grab a file without it being from my normal IP, I can just SSH to the right user on my server and it just works - no configuration, no needing to interrupt other traffic.
Yeah sure.
I'm going to assume you're starting from the point of having a second linux user also set up to use rootless podman. That's just following the same steps for setting up rootless podman as any other user, so there shouldn't be too many problems there.
If you have wireguard set up and running already - i.e. with Mullvad VPN or your own VPN to a VPS - you should be able to run ip link to see a wireguard network interface. Mine is called wg. I don't use wg-quick, which means I don't have all my traffic routing through it by default. Instead, I use a systemd unit to bring up the WG interface and set up routing.
I'll also assume the UID you want to forward is 1001, because that's what I'm using.
I'll also use enp3s0 as the default network link, because that's what mine is, but if yours is eth0, you should use that.
Finally, I'll assume that 192.168.0.0 is your standard network subnet - it's useful to avoid routing local traffic through wireguard.
#YOUR_STATIC_EXTERNAL_IP# should be whatever you get by calling curl ifconfig.me if you have a static IP - again, useful to avoid routing local traffic through wireguard. If you don't have a static IP you can drop this line.
[Unit]
Description=Create wireguard interface
After=network-online.target
[Service]
RemainAfterExit=yes
ExecStart=/usr/bin/bash -c " \
/usr/sbin/ip link add dev wg type wireguard || true; \
/usr/bin/wg setconf wg /etc/wireguard/wg.conf || true; \
/usr/bin/resolvectl dns wg #PREFERRED_DNS#; \
/usr/sbin/ip -4 address add #WG_IPV4_ADDRESS#/32 dev wg || true; \
/usr/sbin/ip -6 address add #WG_IPV6_ADDRESS#/128 dev wg || true; \
/usr/sbin/ip link set mtu 1420 up dev wg || true; \
/usr/sbin/ip rule add uidrange 1001-1001 table 200 || true; \
/usr/sbin/ip route add #VPN_ENDPOINT# via #ROUTER_IP# dev enp3s0 table 200 || true; \
/usr/sbin/ip route add 192.168.0.0/24 via 192.168.0.1 dev enp3s0 table 200 || true; \
/usr/sbin/ip route add #YOUR_STATIC_EXTERNAL_IP#/32 via #ROUTER_IP# dev enp3s0 table 200 || true; \
/usr/sbin/ip route add default via #WG_IPV4_ADDRESS# dev wg table 200 || true; \
"
ExecStop=/usr/bin/bash -c " \
/usr/sbin/ip rule del uidrange 1001-1001 table 200 || true; \
/usr/sbin/ip route flush table 200 || true; \
/usr/bin/wg set wg peer '#PEER_PUBLIC_KEY#' remove || true; \
/usr/sbin/ip link del dev wg || true; \
"
[Install]
WantedBy=multi-user.target
There's a bit to go through here, so I'll take you through why it works. Most of it is just setting up WG to receive/send traffic. The bits that are relevant are:
/usr/sbin/ip rule add uidrange 1001-1001 table 200 || true; \
/usr/sbin/ip route add #VPN_ENDPOINT# via #ROUTER_IP# dev enp3s0 table 200 || true; \
/usr/sbin/ip route add 192.168.0.0/24 via 192.168.0.1 dev enp3s0 table 200 || true; \
/usr/sbin/ip route add #YOUR_STATIC_EXTERNAL_IP#/32 via #ROUTER_IP# dev enp3s0 table 200 || true; \
/usr/sbin/ip route add default via #WG_IPV4_ADDRESS# dev wg table 200 || true; \
ip rule add uidrange 1001-1001 table 200 adds a new rule where requests from UID 1001 go through table 200. A table is a subset of ip routing rules that are only relevant to certain traffic.
ip route add #VPN_ENDPOINT# ... ensures that traffic already going through the VPN - i.e. wireguard traffic - does. This is relevant for handshakes.
ip route add 192.168.0.0/24 via 192.168.0.1 ... is just excluding local traffic, as is ip route add #YOUR_STATIC_EXTERNAL_IP
Finally, we add ip route add default via #WG_IPV4_ADDRESS# ... which routes all traffic that didn't match any of the above rules (local traffic, wireguard) to go to the wireguard interface. From there, WG handles all the rest, and passes returning traffic back.
There's going to be some individual tweaking here, but the long and short of it is, UID 1001 will have all their external traffic routed through WG. Any internal traffic between docker containers in a docker-compose should already be handled by podman pods and never reach the routing rules. Any traffic aimed at other services in the network - i.e. sonarr calling sabnzbd or transmission - will happen with a relevant local IP of the machine it's hosted on, and so will also be skipped. Localhost is already handled by existing ip route rules, so you shouldn't have to worry about that either.
Hopefully that helps - sorry if it's a bit confusing. I learned to set up my own IP routing to avoid wg-quick so that I could have greater control over the traffic flow, so this is quite a lot of my learning that I'm attempting to distill into one place.
One of the really nice side-effects of it running rootless is that you get all the benefits of it running as an actual Unix user.
For instance, you can set up wireguard with IP route to send all traffic from a given UID through the VPN.
Using that, I set up one user as the single user for running all the stuff I want to have VPN'd for outgoing connections, like *arr services, with absolutely no extra work. I don't need to configure a specific container, I don't need to change a docker-compose etc.
In rootful docker, I had to use a specific IP subnet to achieve the same, which was way more clunky.
The websockets work has been merged. I'm using it on my instance now, but there's no release yet. It's been really stable for me so far, so I'm hoping there aren't major issues and they can push it out soon.
I'm all in on docker-compose + rootless podman. Definitely not no issues, but I've got the hang of the kinds of issues it presents at this point. They're mostly around SELinux and networking, though generally the networking only gets problematic on exotic compose setups - jitsi was a huge pain for me.
Raw server with SSH and an immutable OS too. I'm using fedora IOT for my homeserver, and apart from some initial issues with GPU drivers because of layering issues (now working) that's been basically flawless.
I was on OpenSuse MicroOS, but I had huge problems with BTRFS and decided to give it up in favour of EXT4 + XFS. That necessitated moving distro, because MicroOS uses BTRFS snapshots as the basis for its auto-updating/green/blue system. Fedora IOT uses rpm-ostree instead, and works on any filesystem.
I've seen a couple of people mention this bug. I'll check if there's an issue in their bugtracker for it.
It'll stop soon. The Devs are currently pushing through a big UI rework that changes the way the frontend communicates with the backend. Once that's released and your instance updates, the auto-refreshing will end.
If there are bugs that pop up that need solving, I'd be happy to contribute. Feel free to DM me with anything specific, the main Devs definitely have a few big things on their plate.
For the moment I'm planning to start getting familiar with the codebase.
OK, I've just realised something new - images pulled from websites as thumbnails are uploaded to the server and appear to be basically full sized, i.e.:
https://agora.nop.chat/pictrs/image/59cfdd9c-2f69-4e8d-8afc-6fbc0c1cca87.jpeg
This image is on my server, but it's just pulled from the website as a thumbnail. This doesn't seem to be super consistent in how it's handled - I'm continuing to look at what's causing it and why it doesn't seem to happen all the time.
EDIT: Seems like there's more on there than I expected. Gonna continue digging.
How are the Trådfri bulbs? I haven't tried them out yet. It'd be good to have a cheaper option.