docker-compose is great, but I love using @fedora CoreOS lately and I want to use the built-in tools it provides. I also want automatic updates without a privileged watchtower container running.
I've released version 1.19.0-3 of my @nlnetlabs#unbound#docker image with updated build environments and unbound base to #alpinelinux 3.19.0. I have reduced two image layers by adding a separate build stage. The tags of the build environments got pinned for better #reproducibility, too.
If I remember correctly, at one point my Home Assistant (H-A from now on) installation started complaining on the Bluetooth component not starting up correctly. Since I wasn’t using Bluetooth (the server doesn’t even have the hardware for it) I just ignored it.
Until a few days ago. I wanted to start playing with ESPHome, and that integration has the Bluetooth component as a required dependency.
Lots of searching later, I did have some clues. It seems others had run into the same issue, with the only suggested solution being to add –privileged to the containers. Now that’s no good, I run all my services rootless for security reasons and so should you. I realized I would need to figure out that actual root cause myself.
The key information gleaned from the log is that it has to do with dbus authentication getting rejected:
File "/usr/local/lib/python3.10/site-packages/dbus_next/auth.py", line 78, in _receive_line raise AuthError(f'authentication failed: {response.value}: {args}')dbus_next.errors.AuthError: authentication failed: REJECTED: ['EXTERNAL']
This lead to some additional guidiance from similar issues being solved with keeping the user namespace, again, not something you want to do with rootless containers. At this point it seems clear I need to figure out what dbus makes the decision to reject the authentication on – and after I while I end up at a non-resolved five year old libdbus issue thanks to a discussion on the Qt issues board.
This seems promising! I got to work setting up a VM with Alpine Linux in, patching libdbus and then transfering that lib over to my H-A container only to find out that … it made no difference whatsoever. This had me stumped for a while, until I looked into the actual Python libraries used.
“dbus-fast: A faster version of dbus-next originally from the great DBus next library. dbus-fast is a Python library for DBus that aims to be a performant fully featured high level library primarily geared towards integration of applications into Linux desktop and mobile environments. dbus-fast plans to improve over other DBus libraries for Python in the following ways: Zero dependencies and pure Python 3
Zero dependencies? Not using libdbus? I jumped into the live Python code in my container and found where authentication was made. Indeed the code is able to handle both the case with a supplied user id and without, so I assumed that somewhere in the H-A code or parent component dependency one was supplied even when running within rootless containers. I made an ugly patch to always enforce the no-id case and restarted my container.
ESPHome loaded up perfectly fine. I even dug up a USB Bluetooth adapter and plugged into the server and was greeted by H-A immediately recognizing and configuring it.
I added the ugly patch to my existing H-A docker container Dockerfile and it’s been working since. Now, maybe I should go find out whethere dbus-fast, or the bluetooth-adapters component that pulls it in within H-A, should make a change – but I’ll leave it here having documented it both on Mastodon, on my blog and also as a comment on the H-A community forums.
And if you’ve run into this issue, here’s how you can solve it in your Dockerfile too. Make sure to copy the contents, there’s a bunch of whitespace needed to align the code correctly.
# patch dbus-fast to not use AUTH EXTERNAL ID<br></br>RUN /bin/sed -i '/self.negotiate_unix_fd = negotiate_unix_fd/a self.uid = UID_NOT_SPECIFIED' /usr/local/lib/python3.11/site-packages/dbus_fast/auth.py<br></br>
My daughter was having trouble using Home Assistant dashboards because her hands are tiny and she kept accidentally right clicking. So I made her a toddler friendly interface.
Introducing Home Assistot!
Left or right clicks on any of the sections trigger a correspondingly named Home Assistant script: red, blue, green, & rainbow. I've set those scripts to change the lights.
I realize what I am about to write is going to be unpopular but #docker is cop-out for not providing proper install documentation. I am not a fan of containerized services. When I stand up a service, I want complete control over it.
Something strange happened to me today. A developer reached out because after restarting some #docker containers, nginx seemed to be behaving oddly. I connected and realized something big was off. It appeared to be a different container, bloated, and nginx wasn't even starting. After ruling out the possibility of the nginx image from the docker registry being compromised, we started to brainstorm. Long story short, another developer had created a custom image and named it "nginx," so the dockerfile was pulling it directly from the local setup... #DockerTroubles#Linux#Containers
⚠️ No more deprecation warnings with #Symfony 6.3 (and 6.4-dev)
📦 6x faster #Docker builds
🧑🏭 Skaffold support (#Kubernetes development)
🐛 Many bug fixes
Hier hat mir vor einiger Zeit mal jemand Bzgl. #Docker und #Invidious geholfen. Wer war denn das? Ich brauch da nochmal Hilfe (hab grad wieder frisch installiert).
🔴 Today on #SystemCrafters Live, we'll attempt to produce minimal Docker container images for various purposes using the 'guix system docker-image' command. Let's see how much we can cut out to make our containers as minimal as possible!