-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mount /etc/machine-id as optional default to support D-Bus #1050
Comments
Thanks @loveshack. I was not familiar with this file. Looks like it is a unique ID of the OS installation (man page, Debian wiki). So by bind-mounting it from the host, we declare that the host and the container are the same OS installation. That's certainly a kludge, but it could be a good kludge. Questions:
|
I spoke with my colleague @mej about this, who's an expert on such matters. His opinions:
Given that, I'm inclined to proceed with the proposed solution. |
https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper
says in support: "Some containerized applications require the container
to be synchronized with the host on certain attributes such as time and
machine ID". (Not that I've gone "cloud native".)
|
In case it's still relevant, I should have said that an explicit --bind
works, of course.
[The best I came up with for generating the id with plain POSIX utils
was an od | cut | tr with appropriate args.]
|
I also wanted to quickly add that the images/repositories/ Imagine a distributed application that used the value of End-users can always, of course, fire upon as many of their own feet as they like, but the software should be setting them up for success, not failure. 😁 TL;DR: I recommend that |
That all sounds sensible, and maybe worthy input to https://wiki.debian.org/MachineId!
|
I tried to run a graphical program (paraver) and got a dbus-related error about /etc/machine-id being empty. Mounting that into the container fixes it.
The text was updated successfully, but these errors were encountered: