This was always a lurking issue due to the following command in webcam_stream.py
sarge.run('sudo service webcamd stop')
However, until version 2.3.3, the return code was not checked and the failure to run as root and/or have sudo access and/or have webcamd running as a service was not an issue.
However, the latest code now checks the return code so when the above command fails, it obico assumes that the native RPI h.264 streaming is unavailable and reverts (downgrades) to ffmpeg_from_mjpeg which then fails if you actually have native h.264 stream running.
It seems like webcam_stream.py makes 3 unrelated faulty assumptions:
All users are running a setup like Octopi
Users have root access and/or password-less sudo access
Users are running webcamd as a service to control their webcam
Indeed, there is no reason other than perhaps "convenience" to run Octoprint & Obico as root. It all runs perfectly fine from user space requiring perhaps only group access to 'video'
Running in user space indeed seems much more secure than running as root as there is no guarantee that Octoprint, let alone all of its many possible plugins are not vulnerable to exploit.
More generally, it seems that in several places Obico unnecessarily and implicitly assumes that Octoprint is running under the Octopi distro. For example, it assumes that one uses nginx reverse proxy which is not necessary for Octoprint and the lack thereof breaks the ability to view the video stream unless you are viewing the stream from the Pi itself (localhost). See https://github.com/TheSpaghettiDetective/OctoPrint-Obico/issues/173
While the Octopi distro is nice and easy for new users, there are many, many good reasons not to use a dedicated distro to run Octoprint. For example, I have many pi devices for different applications and I use a common basic setup. Rather than having to manage a separate Octopi distro configuration, I simply installed Octoprint on one of my existing Pi's
As a generally-applicable plugin for Octoprint, it doesn't make sense to me that Obico should be so tied to one distro and implementation of Octoprint. It should be up to the Octopi maintainers to configure their distro to support Obico not the reverse of having Obico configured exclusively/primarily to support the Octopi way of implementation (e.g., nginx reverse proxy, sudo access, webcamd as a service, etc.)
I see your point. But I can't think of a good way to implement a solution that works on all platforms. If you have one solution in mind, please implement it and send an PR. Thanks a lot!
This was always a lurking issue due to the following command in webcam_stream.py
sarge.run('sudo service webcamd stop')
However, until version 2.3.3, the return code was not checked and the failure to run as root and/or have sudo access and/or have webcamd running as a service was not an issue.
However, the latest code now checks the return code so when the above command fails, it obico assumes that the native RPI h.264 streaming is unavailable and reverts (downgrades) to ffmpeg_from_mjpeg which then fails if you actually have native h.264 stream running.
It seems like webcam_stream.py makes 3 unrelated faulty assumptions:
Indeed, there is no reason other than perhaps "convenience" to run Octoprint & Obico as root. It all runs perfectly fine from user space requiring perhaps only group access to 'video'
Running in user space indeed seems much more secure than running as root as there is no guarantee that Octoprint, let alone all of its many possible plugins are not vulnerable to exploit.
More generally, it seems that in several places Obico unnecessarily and implicitly assumes that Octoprint is running under the Octopi distro. For example, it assumes that one uses nginx reverse proxy which is not necessary for Octoprint and the lack thereof breaks the ability to view the video stream unless you are viewing the stream from the Pi itself (localhost). See https://github.com/TheSpaghettiDetective/OctoPrint-Obico/issues/173
While the Octopi distro is nice and easy for new users, there are many, many good reasons not to use a dedicated distro to run Octoprint. For example, I have many pi devices for different applications and I use a common basic setup. Rather than having to manage a separate Octopi distro configuration, I simply installed Octoprint on one of my existing Pi's
As a generally-applicable plugin for Octoprint, it doesn't make sense to me that Obico should be so tied to one distro and implementation of Octoprint. It should be up to the Octopi maintainers to configure their distro to support Obico not the reverse of having Obico configured exclusively/primarily to support the Octopi way of implementation (e.g., nginx reverse proxy, sudo access, webcamd as a service, etc.)