RadDevon

I'm on Bazzite Linux 42 and was having some trouble with my 2.4GHz wireless keyboard disconnecting, so I decided to replace it. The new one is having similar issues despite being a different brand (new: XVX, old: Royal Kludge), so I suspect the culprit may actually have been software all along. I have a 2.4GHz wireless mouse connected to the same system that is generally reliable, so I don't believe it's an issue of 2.4GHz interference. The keyboards work well when connected to my Mac, so I don't believe it's faulty hardware.

This keyboard has one feature that may be helpful in troubleshooting: it flashes an LED when it’s trying to reconnect. (The previous one had no indicator.) I can clearly see that, after the keyboard has been idle for a bit, it starts trying to reconnect again. I suspected a power management issue, but I believe I’ve disabled that. I started with a rule in /etc/udev/rules.d/:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1038", ATTR{idProduct}=="1830", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0c45", ATTR{idProduct}=="fefe", TEST=="power/control", ATTR{power/control}="on"

(These rules disable power management for both keyboard and mouse, just in case.) I got the IDs with lsusb. I’m assuming the part of the ID before the colon is the vendor ID and the part after is the product ID.

That didn’t seem to help at all, so I tried disabling USB power management with rpm-ostree kargs --append-if-missing="usbcore.autosuspend=-1". That made the problem better, but now it just seems to take longer (a couple of minutes) for the keyboard to lose connectivity. Also, now when it loses connectivity, it seems even disconnecting and reconnecting the dongle doesn't always fix it.

Anyone have ideas what I might try from here?

I'm in the process of setting up backups for my home server, and I feel like I'm swimming upstream. It makes me think I'm just taking the wrong approach.

I'm on a shoestring budget at the moment, so I won't really be able to implement a 3-2-1 strategy just yet. I figure the most bang for my buck right now is to set up off-site backups to a cloud provider. I first decided to do a full-system backup in the hopes I could just restore it and immediately be up and running again. I've seen a lot of comments saying this is the wrong approach, although I haven't seen anyone outline exactly why.

I then decided I would instead cherry-pick my backup locations instead. Then I started reading about backing up databases, and it seems you can't just back up the data directory (or file in the case of SQLite) and call it good. You need to dump them first and backup the dumps.

So, now I'm configuring a docker-db-backup container to back each one of them up, finding database containers and SQLite databases and configuring a backup job for each one. Then, I hope to drop all of those dumps into a single location and back that up to the cloud. This means that, if I need to rebuild, I'll have to restore the containers' volumes, restore the backups, bring up new containers, and then restore each container's backup into the new database. It's pretty far from my initial hope of being able to restore all the files and start using the newly restored system.

Am I going down the wrong path here, or is this just the best way to do it?

I'm running a Docker-based homelab that I manage primarily via Portainer, and I'm struggling with how to handle container updates. At first, I had all containers pulling latest, but I thought maybe this was a bad idea as I could end up updating a container without intending to. So, I circled back and pinned every container image in my docker-compose files.

Then I started looking into how to handle updates. I've heard of Watchtower, but I noticed the Linuxserver.io images all recommend not running Watchtower and instead using Diun. In looking into it, I learned it will notify you of updates based on the tag you're tracking for the container, meaning it will never do anything for my containers pinned to a specific version. This made me think maybe I've taken the wrong approach.

What is the best practice here? I want to generally try to keep things up to date, but I don't want to accidentally break things. My biggest fear about tracking latest is that I make some other change in a docker-compose and update the stack which pulls latest for all the container in that stack and breaks some of them with unintended updates. Is this a valid concern, and if so, how can I overcome it?