jwildeboer, to random
@jwildeboer@social.wildeboer.net avatar

Seems like today a new minor update to #Forgejo (7.0.3) will land. With lots of little bugfixes. Yeah!

jwildeboer, (edited )
@jwildeboer@social.wildeboer.net avatar

It has landed. As I run my own instance as a container on my (Red Hat Enterprise Linux) server, all it took was

#> systemctl stop forgejo
#> podman pull codeberg.org/forgejo/forgejo:7-rootless
#> systemctl start forgejo

And done. Updated to 7.0.3 :)

Release notes at https://codeberg.org/forgejo/forgejo/src/branch/forgejo/RELEASE-NOTES.md#7-0-3

Thank you to all that made it happen, @forgejo :)

deflockcom, to node
@deflockcom@mastodon.social avatar

Anyone have #successfully set up #tailscale as #exit #node on a #rootless #podman ?

(Work on it actually to move all my services on a fedora coreos node)

scy, to random
@scy@chaos.social avatar

Anyone running using and under ? The volumes I'm mapping to the host always get chowned to 100999:100999, and that's with USERMAP_UID=1000 and USERMAP_GID=1000 in docker-compose.env.

Playing around with PODMAN_USERNS mainly leads to the container not starting at all (in at least one case because it can't install packages).

ramikrispin, to datascience
@ramikrispin@mstdn.social avatar

Still looking for reasons to learn Docker?

Source: Github Blog

jornfranke,
@jornfranke@mastodon.online avatar

@ramikrispin Unfortunately, the security of those is often bad (overly permissive, bad security configuration etc.) and the people using them have also no clue how to run them securely ( without privileges, https://rootlesscontaine.rs/ e.g. with ). Here from 2017 (and it got now MUCH worse): https://dl.acm.org/doi/abs/10.1145/3029806.3029832 . See also: https://computer.rip/2023-11-25-the-curse-of-docker.html

It is often better not to use it than to use it insecurely.

blog.troed.se, to homeassistant

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

https://pypi.org/project/dbus-fast/

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>

https://blog.troed.se/2023/12/11/bluetooth-and-home-assistant-in-rootless-docker/

neverpanic, to random
@neverpanic@chaos.social avatar

I'm speaking at about this afternoon. There will be a live stream, so tune in if you want! I'm convinced we all need to use less root in our lives 😉

https://devconfcz2023.sched.com/event/1MYkl/rootful-networking-with-rootless-podman-containers

ljrk, to random
@ljrk@todon.eu avatar

After reading a lot of Dan Walsh's articles on the matter, for the first time in my life I feel like understanding , , , and , and how they differ in Docker vs. Podman. Which just means I misunderstood enough to be dangerous.

(tbf, I come from a probably not-so-common perspective of having had an okayish grasp of user namespaces but didn't grok podman.)

  • All
  • Subscribed
  • Moderated
  • Favorites
  • megavids
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • JUstTest
  • All magazines