MMM-Remote-Control: MMM-Remote-Control doesn't work with docker installation
Gosh this module is bliss! Loved it instant even if it doesn’t work for me.
I mean, this is not an issue, it’s by design. But I would party hard if we can Frankenstein something together to make it work with Docker. The docker setup: https://gitlab.com/khassel/magicmirror and used in the MagicMirrorOS which is mentioned on the main project site: https://github.com/guysoft/MagicMirrorOS
OK what happens? Module installation is easy and works out of the box.
- cd /home/pi/magicmirror/mounts/modules
- Do the git clone
- Execute: docker-compose exec -it bash
- cd /home/pi/magicmirror/modules/MMM-Remote-Control
- npm install
- Add it to your config file and voilà you can straight away see it on a different machine, since the whitelist is empty and the listener is set to 0.0.0.0.
And here comes the problem. As soon as you try to use halt/restart/monitor control you end up with:
What’s the point? Well obviously the command is executed inside the docker container. Checked node_helper.js and found the line which sends the command to the system: It’s simple “shutdown -h/r now”. Looking deeper inside I checked the command right inside the container and received:
docker exec -it mm bash node@magicmirroros:/opt/magic_mirror$ sudo shutdown -h now System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host i
Yes, true by design you don’t want that a container can shut down the system. BUT 😭 that’s sad. Really this module would save me a lot of time diggin’ around how to control a Pi with MQTT.
Question: Somebody knows how to deal with it. Yes I know it might be dangerous to let a container control your system. That’s not the point. The point is - is there a way?
BUT all in all - great idea, nicely done. Thanks for contributing it to the community. I will try to find a solution, but I am not a JavaScript guy 😃 I have done one module and it felt like hell to me. To stupid maybe XD don’t know but I don’t get JavaScript.
If you have something or a page or a link where to search I would try it. Maybe there is a solution, and we can add the possibility to add a “docker=1/0” to this plugin. Or a workaround that would be a great thing.
Cheers and keep up your good work - Clyde
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 22 (5 by maintainers)
@goldyfruit
Results of your question:
Maybe removing :ro from /run/systemd?
Removing :ro from volumes result in the same problem 😕 gnarf. Maybe we should move on - doing something better instead of creating a security nightmare XD
I already frankenstein’d a MQTT listener together which works nice to shutdown the system via OpenHab2 in the end. Thanks for all the help. I will keep this one open for the next few days and close it after. If someone wants me to try other stuff - I will try to do so.
Thx @ezeholz Thx @goldyfruit ❤️
Glad to see that the internet is not entirely filled up with idiots 😃 you rock! And have a nice day.
I managed to reboot my RPi from a Docker container. Two things were missing:
(Just in case, backup your stuffs before doing anything)
Try this:
Again from a security perspective it’s pretty bad but you seems to be aware of that so, so far so good 👍
Woah thx for all the input. Will try this in the next few days. You know Halloween approaching hard! XD But super happy 😃 report back. Just give me a few days.
Cheers and Happy Halloween - take care everyone!
@crimsonclyde Docker needs to communicate with
systemd
on the host to perform this type of action.I guess you are using the
rpi.yml
(from the Docker setup you mentioned above), try to add this to the mount list:Which based on this https://gitlab.com/khassel/magicmirror/-/blob/master/run/rpi.yml should become: