Document using cgroup rules to start container without USB #158
Comments
|
The real challenge here is not adding the cgroup rule, but the fact that you have to know the state of the desired device when the container starts. If it is connected, you need to include the device in the container startup. If it isn't, then having added the udev rule will cause the device to be added when it is detected. This is just as bad as trying to start a container without the device, because it means you have to know the state of the printer prior to container startup regardless of if you have these device rules in place. You could easily create a systemd unit file that uses a script to start the octoprint container, and that script checks for a device and includes it in container startup if it exists, but you've now once again tied the system to the container. |
|
Basically, we could support systemd type systems, and provide that script, and then tell anyone using portainer or any other tool that manages containers that they would be on their own to figure out how to do a dynamic container start? |
LongLiveCHIEF
added
Documentation
Research
LongLiveCHIEF
removed
the
Research
|
I came across this Reddit post, https://www.reddit.com/r/octoprint/comments/klxzpr/docker_mapping_printer_to_usb_port/ and with your and wingjames' help was able to successfully set it up so that I can start Octoprint with the printer turned off. I was trying to think of a more elegant solution like you want and came across this, https://github.com/marthoc/docker-deconz/issues/298, where it seems that someone else is doing what you want. I couldn't quite figure out all the pieces to put it together or find in the code where they were setting up the devices or anything. Maybe it will point you in the right direction. |
|
@reverendj1 perhaps see this gist. It’s a brute force solution but it does actually work. I’m running OctoPrint in a Docker container on a Pi 3B+. I’ve also tested the approach on a Pi 4 with other detachable devices like a Zigbee adapter. |
|
I've already got the work for all this done, (it's a really simple single-line script for udev rules), just haven't had time to finish the PR to share docs. |
|
Hello all, I had the same issue with my printer. Usually it is powered off. If I tried to restart my raspi or the octoprint container, it failed because of the missing usb device. So my current solution is also to use Dockerfile (take original Dockerfile and add following line before the ENTRYPOINT):This command create a new script in the Build the new docker image: docker-compose.yml (add following configuration changes to your existing file): |
Any chance you could share this one liner here so other less adept folks (like me) can use while you’re assembling the PR? |
|
Anything else needed other that adding this file to say /usr/lib/udev/rules.d and rebooting. |
|
An alternative solution I'm using to this script above is to create a wrapper init script in conjunction to the cgroup rules. There's nothing which says the character devices need to be added to the filesystem dynamically, given that the printer is the only serial device connected to this system. I've placed the script in the octoprint volume and it looks something like this: #!/bin/sh
mknod c 166 0 /dev/ttyACM0
mknod c 166 1 /dev/ttyACM1
/init $@On my system the Rambo board uses device major 166. I then execute the script using docker flag |
Hi, /etc/udev/rules.d/90-octoprint.rules Script drucker.sh (chmod +x): compose-file for octoprint |
|
I experienced some real pain and suffering trying to get this to work, but got there in the end.
Notes for newbies:Just a note for anyone finding this thread, here are a few unspoken things that are important, taking into account you have read the whole issue thread and are now here:
|
|
I struggle with this to work but without success.
effects:
|
|
are you sure your device uses ttyUSB and not ttyACM? Also, are you sure your printer is on USB0 and not USB1 or another enumerated USB device port? The reason i haven't merged any of this documentation yet, is because there are generally no "universal" rules and instructions that work for everyone. There's not even a good set that works for the majority. This is part of the container way of life unfortunately. |
|
yes, it was always ttyUSB0, with
in addition to that after I connect printer: |
|
hurray, found the solution. I had to enable previliged mode |
This worked well for the printer, how would this translate for the webcam? |
|
There is more simple solution: (merge this with your docker-compose.yml) We are just mounting whole /dev (all nodes), but only to some of them granting access. No udev rules, no scripts, use with pleasure! |
There are many many reasons why this is a bad idea. |
This is true if they don't have cgroup rules limiting access to only the specific device MAJOR and MINOR identifiers within /dev. I believe with the correctly scoped cgroup rules it's OK as long as the devices being passed through are only in use by the container and not also the root user on the host. |
|
Yep, there is normal, absolutely, we can mount all system tmpfs into container and until our process fully cgrouped, this mounts will grant only information, the containered process can't do anything with root resources. Btw, guys, it's home printing server, use normal router with firewall and relax, it must be comfortable, must! PS @LongLiveCHIEF we with @sammcj know how to use containers, trust us!) |
|
If anyone knows how to force udev to create second, real block-file for connected device (not just a symlink), it will be better! |
That's not good advice @lictw, you're making a lot of assumptions about how and where people host their Octoprint and how their Firewalls are setup. People absolutely should be doing their best to secure wherever Octoprint runs.
🤦 |
|
Also, if you're allowlisting devices with a MAJOR of You might be better advising people to stick to something like: device_cgroup_rules:
- 'c 188:* rmw' # access to usb serial devices like /dev/ttyUSB0, /dev/ttyUSB1 etc... when using CH340 USB serial adapters with the MAJOR of 188
- 'c 81:* rmw' # access to video and webcam devices like /dev/video0, /dev/video1 etc... when using Logitech webcams with the MAJOR of 81If they experience problems they could try adding specific MAJOR 1 devices such as: # Only ever use this as a LAST RESORT, NEVER in production and ALWAYS make sure cgroup rules are applied and set correctly!
device_cgroup_rules:
- 'c 1:3 rw' # access to /dev/null
- 'c 1:5 rw' # access to /dev/zero
- 'c 1:8 rw' # access to /dev/random
- 'c 1:9 rw' # access to /dev/urandomInside the container this limits /dev to: A list of device names with their MAJOR and MINOR IDs can be obtained by running: stat -c '%n major: %t minor: %T' /dev/* |
|
You're right, /dev/mem was very reckless, it's really better to give personal access if the program needs special devices. |
|
And okay, who want the security? I will add it for you: What is it: it's a 'one-liner' that will create huge mount list, this mounts will override all real char/block-devices (except required) with /dev/null and mount tmpfs into all /dev/* directories, without a rights the access is useless, but after this it will be inaccessible in a principle. PS: Yes it's a blacklist, but it's more then nothing!) |
|
Couple ideas:
|
This is the ideal solution for me so far. Not sure about the author, but device is not hotpluggable. I did have to restart container after plugging in. I'm fine with that. It's a lot better than destroying container, rejigging the config and re-creating. I think you could make it fully hotpluggable by using a volume instead of device for /dev/bus/usb. Some additional pointers on the original solution: ^Note how I needed to change ownership and permissions to use the devices |
|
Hi! I just updated the full instructions in case anyone needs it... Configuration for 3D Printer hot-plug in Docker containersThis configuration allows the container to start without a 3D printer plugged and will automatically detect and update the device list when the printer is turned on. It was tested on a brand new Raspian Bullseye 32-bit image (version 11.7) with Docker (24.0.6) from the official website (not the Rasperry PI repository). Octoprint version was 1.9.2. The only change required for the host system is the creation of the udev rule. Container is not rebuilt, no privileged user permissions are required, there is no need to mount the
# allow usage/start of the container regardless of whether printer is connected
SUBSYSTEM!="tty", GOTO="end_octoprint_printers"
ACTION=="add|change", SUBSYSTEM=="tty", KERNEL=="ttyUSB[0-9]|ttyACM[0-9]", RUN+="/usr/bin/docker exec octoprint rm -rf /dev/3dprinter", RUN+="/usr/bin/docker exec octoprint mknod /dev/3dprinter c %M %m"
ACTION=="remove", SUBSYSTEM=="tty", KERNEL=="ttyUSB[0-9]|ttyACM[0-9]", RUN+="/usr/bin/docker exec octoprint rm -rf /dev/3dprinter"
LABEL="end_octoprint_printers"
Example: version: '3.6'
services:
octoprint:
image: octoprint/octoprint
container_name: octoprint #this should be equal to the udev rules you created
restart: unless-stopped
#privileged: true
ports:
- 5000:80 #Map to external port 5000
device_cgroup_rules:
#Insert your MAJOR ID numbers below
- 'c 166:* rmw' # access to usb serial devices like /dev/ttyUSB0, /dev/ttyUSB1 etc... when using USB serial adapters with the MAJOR of 166
- 'c 188:* rmw' # access to usb serial devices like /dev/ttyACM0, /dev/ttyACM1 etc... when using USB serial adapters with the MAJOR of 188
- 'c 81:* rmw' # access to video and webcam devices like /dev/video0, /dev/video1 etc... when using Logitech webcams with the MAJOR of 81
- 'c 1:3 rw' # access to /dev/null
#- 'c 1:5 rw' # access to /dev/zero
#- 'c 1:8 rw' # access to /dev/random
#- 'c 1:9 rw' # access to /dev/urandom
#devices:
# use `python -m serial.tools.miniterm` to see what the name is of the printer, this requires pyserial
# - /dev/ttyACM0:/dev/ttyACM0
# - /dev/video0:/dev/video0
volumes:
- ./octoprint:/octoprint
environment:
- TZ=America/Sao_Paulo
# - ENABLE_MJPG_STREAMER=true
####
# uncomment if you wish to edit the configuration files of octoprint
# refer to docs on configuration editing for more information
####
#config-editor:
# image: linuxserver/code-server
# ports:
# - 8443:8443
# depends_on:
# - octoprint
# restart: unless-stopped
# environment:
# - PUID=0
# - PGID=0
# - TZ=America/Chicago
# volumes:
# - octoprint:/octoprint
#volumes:
# octoprint:
|
|
@danpeig I had to dig around the web so much to find this thread, and eventually your comment. Thank you for providing instructions! One thing I am unsure about: Is a webcam meant to function with the configuration as you've given it? Mine is not, and I've noticed the only "Additional Serial Port" your instructions mention is one identified as /dev/3dprinter. Not sure if that would be a bundle of all relevant devices from the udev script, or if something separate needs to be configured to get video output. If you don't beat me to it with an answer I'll come back to this when my headache goes away. :-) Edit: Forgot to mention that I'm running this in Portainer, rather than straight out of Docker. Maybe that has something to do with it? Not sure if that would interfere with step 7. |
|
Hi, The udev rules apply only for the 3d printer because it may be turned off when you start the container. This allows hot plugging the printer. I assumed the camera is always connected to the computer, therefore, no udev rule. You can map the camera from the compose file using the "cgroups" section or using the "devices" section. The second one is more common and you will find more details about it over the internet. I personally do not access the camera hardware directly from Octoprint container. I use another container with "go2rtc" to do this job and generate the mjpeg stream that I can access from Octoprint. This way I can use the same camera for other purposes. |
|
Howdy! The camera does work when using the 'devices' section, and you are right that I don't plan on turning it off or disconnecting it at any point unlike the printer. What led me to expect that it would work using your configuration as-is was this line:
The 'devices' solution works for me, but now I'm wondering what extra steps would be required to get the camera working using cgroups & udev. I've been messing around with variations of what follows below. If it's not clear, I'm just guessing at a possible solution! Compose File: udev rules: And in the "Additional Serial Ports" section of Octoprint, I have added: Update: I've realized that the "Additional Serial Ports" section of Octoprint is probably just dealing with the type of connection that would be established with the printer. What I added in there doesn't server a purpose if that's the case. Also actually bothered to look up the name of the video subsystem, and it's "video4linux" and not just "video" so I've changed that. Still not working, will update when I figure it out. |
|
Alright I've got nothing. I'm guessing the webcam bit might need to be done through mjpg streamer or whatever it is that handles the camera feed in Octoprint. @danpeig Would you be able to provide me with an example of how to set up the camera with cgroups? I can't figure it out or find anything that is helping me. |
|
Hi. I can't help you with that. Not sure how Octoprint handles the camera hardware internally. |
Alright, well I can't figure out how to mess with MJPG Streamer within the docker container. I'll just set something else up to manage the webcam like you have. One other thing. I've noticed that when the Octoprint container turns on, it doesn't know the state of the printer. If the printer is on, it needs to be turned off and on again to update. Any way around that, that you know of? |
|
I use the PSU control plugin to turn the printer on and off remotely. It offers several ways of sensing the printer state. |
|
Alright, so it looks like there's an option in OctoPi specifically that allows you to specify a camera, as seen here. I wonder if there would be something similar living in the docker image? Update: I've tried the following configuration, no luck. Docker Compose Udev Update: I've tried some variations on that configuration, and am largely getting the following spat out at me. It doesn't seem to see the webcam. For now I'm going to move on to setting the camera up through go2rtc like suggested a few posts back. If anyone picks this up and tries to get the webcam to work in the same way as the printer, let me know!
|
|
In case you need, here is my go2rtc MJPG Base configuration for Octoprint. |
from https://discordapp.com/channels/704958479194128507/753995646218010674/792045233600856066
Powering off the printer octoprint controls during idle time is a common requirement of OctoPrint users. Docker will fail to start if you try to pass it a usb serial device if that device does not yet exist, and in addition, the device could be assigned a different binding depending on what usb port its plugged into or what order that usb device is booted.
The solution here will be to create a custom cgroup-rule, mount that, and create a udev rule which adds the device to the container when it is added. see: Dealing with dynamically created devices (--device-cgroup-rule)
The issue here of course is that the user may not be using a static name for the octoprint container, so this may only work in circumstances where you're using
docker runordocker-composewith ancontainer_nameThe text was updated successfully, but these errors were encountered: