[bug/feat] Device files in the container

[lazyoldbear]

The way the official container is created, it contains a lot of device files (created explicitly, all right). Including the essential ones, like /dev/ttyACM[01].
Now, that might be convenient if one just runs the thing throught a container engine, or is fine living with privileged in orchestrators.
There is, however, a better way, at least for Kubernetes: smarter device manager. It propagates host resources to the nodes, and allows also to keep track over allocation (so that you don't start two pods asking for the same dongle). And no more privileged.
However, the existence of a device with the same numbers in the container interferes, so that the device file is not created. Since the access to the device is propagated, you can still use the device in an unprivileged container, but it requires to know the naming, which is hard to maintain over reloads.

The suggestion, which can be interpreted either as bug or feature request, is to remove device files from the official container.

[robertsLando]

is to remove device files from the official container

Are you able to draft this in a PR?

[lazyoldbear]

Perhaps, although not instantly: I have neither any environment at hand to play with Docker, nor a registry.

However, I reckoned that whoever chose to add the devices, did it on purpose, so it would feel safer to first clarify if those reasons interfere with the current issue.

[blhoward2]

The docker container contains a full linux distribution, so the dev files are populated by the distribution’s setup. They’re in the base image. I’ve never tried, but I don’t think you can do away with them there or you are going to cause a host of other issues and the container won’t start. Many of them are created by the kernel in any event and would just reappear. Nor can you just map to the host dev files because then the docker couldn’t be run on non-linux systems.

Even if you could do it, this would add complication to the installation as you have to run a second container with the device manager (per the article you cited). And, as the article you cite notes, this reduces system-wide security on the host so many people are going to object to doing so. The device manager also supports a limited number of distributions as far as I can tell (raspbian, Debian, and Ubuntu), and would prevent the image from running on windows/OSX all all. It seems like a very custom use and so one that I’m sure could be accommodated with a custom-built image. Or you can attach to the container and simply delete them on your end. Have you tried to do that on an image to see if it even works?

I’m not sure how their being there causes a conflict, either, otherwise this would not work with Linux-based images, which is a huge number of them. In docker you can just map right overtop of them as a Volume if you like. I think you may be configuring it incorrectly...

The project page suggests that it reads the HOST dev files and then exports resources to the container kernel. That makes much more sense. It then maps specific resources into the container dev file (as I understand it). So you could have /dev/ttyUSB0 map into the container as /dev/zwave, and its access would then be brokered. It isn’t a replacement for all of the device files, nor could it be.

@robertsLando Recommend closing this one as unfulfillable.

[lazyoldbear]

@blhoward2 That is just incorrect. As a quick experiment, compare the image internals with the base (node:erbium-alpine). It does have some devices, necessary for basic operations like tty and stuff.

Looks like this comes through Dockerfile ARG updateDevices (line 4), which is used to trigger a violent action on line 31.
Killing the ARG is not at all unfullfilable, but I assume that there is a less dramatic way, like narrowing the set of devices to really necessary. Or even migrating to the entrypoint.

[blhoward2]

@blhoward2 That is just incorrect. As a quick experiment, compare the image internals with the base (node:erbium-alpine). It does have some devices, necessary for basic operations like tty and stuff.

Looks like this comes through Dockerfile ARG updateDevices (line 4), which is used to trigger a violent action on line 31.
Killing the ARG is not at all unfullfilable, but I assume that there is a less dramatic way, like narrowing the set of devices to really necessary. Or even migrating to the entrypoint.

The docker files build off Dockerfile.contrib as far as I know. At least they do when you manually build them using the docker build kit. Have you tried building one that way to see if it fixes your issue? I’ve never tried Kubernetes so perhaps those build differently.

Some /dev files are generated by the kernel as it detects devices, so I wouldn’t at all be surprised if a pre-run diff was different than the final container. Have you actually spun up an image without that arg to see if it is adding anything?

[lazyoldbear]

No, I don't even have Docker anywhere, or anything else that builds images.
Besides, I don't need to build it: I know that if creating "excessive" device is removed, everything will work properly (because no dev files with relevant number pairs will be present in the system).
However, as I mentioned above, I assume that whoever started creating them devices, did it on purpose.
So I assumed that asking a question might be a quick way to bring the context in sync with possible stakeholders.

[lazyoldbear]

But I did try pods on zwavejs2mqtt and node:erbium-alpine, to make sure.
What I did not try is to alter zwavejs2mqtt specifically, for it requires building an image and putting it to some registry.

[blhoward2]

Just spin up the base image like you would the zwavejs2mqtt image and see if they are there?

[lazyoldbear]

Yes, that I did, in the first place. Apologies for not being clear.

[blhoward2]

And they were not in the base image? Could you list the specific device files (some examples)?

[lazyoldbear]

All right, the problem was in the chart. It had default privileged: true, and needed explicit false.
I am sorry for the fuzz.

[blhoward2]

Glad you got it figured out. I was surprised it would be that breakable.

[lazyoldbear]

Well, I was confused by the black magic with devices.
And the last thing I expected from a chart is to have privileged as default (working on a pull request there). :-)
Sorry again.