Skip to content
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

Closed
loveshack opened this issue May 3, 2021 · 6 comments
Closed

mount /etc/machine-id as optional default to support D-Bus #1050

loveshack opened this issue May 3, 2021 · 6 comments

Comments

@loveshack
Copy link
Contributor

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.

loveshack added a commit to loveshack/charliecloud that referenced this issue May 3, 2021
@reidpr reidpr self-assigned this May 3, 2021
@reidpr reidpr changed the title /etc/machine-id may need mounting mount /etc/machine-id as optional default to support D-Bus May 3, 2021
@reidpr
Copy link
Collaborator

reidpr commented May 3, 2021

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:

  • Are you aware of any arguments that this is or is not a best practice for containers?
  • --bind /etc/machine-id is available now as a workaround; is that sufficient for your use case?
  • If we do want to initialize the file with unique but properly formatted value, it's straightforward to do this with /dev/urandom and POSIX tools.
  • Would a FAQ entry be sufficient for your use case?

@reidpr
Copy link
Collaborator

reidpr commented May 3, 2021

I spoke with my colleague @mej about this, who's an expert on such matters. His opinions:

  • There does not appear to be a consensus on whether container /etc/machine-id should match the host or be generated new for each container.
  • It does seem that the file should contain a valid value when the container is running. On the other hand, when not running the file should be empty. (This implies that if we don't match the host, we need to keep track of the value some other way.)
  • This ID is sometimes used for software licensing, which points to matching the host.
  • Bind-mounting from the host seems to be a common approach (e.g. 1 2).

Given that, I'm inclined to proceed with the proposed solution.

@loveshack
Copy link
Contributor Author

loveshack commented May 4, 2021 via email

@loveshack
Copy link
Contributor Author

loveshack commented May 4, 2021 via email

@mej
Copy link
Member

mej commented May 7, 2021

I also wanted to quickly add that the images/repositories/rootfs artifacts that provide the "initial state" of the filesystem for each container should always be empty or missing (preferably the former); this avoids the potential "worst-case" situation: unintentionally having multiple running containers on multiple physical hosts seeing a non-unique value for something that - in theory - is guaranteed to be unique among disparate physical entities.

Imagine a distributed application that used the value of /etc/machine-id to choose between, say, TCP/IP sockets for remote comms vs. UNIX sockets for optimized local comms; if all the containers on all the hosts thought they were all local and tried to communicate that way...well, I suspect hilarity would ensue! 😜

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 /etc/machine-id be (1) a zero-byte file in the directory/filesystem image and (2) bind-mounted from the host at runtime.

@loveshack
Copy link
Contributor Author

loveshack commented May 7, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants