This PR templatizes the Janus main config file, and adds a privileged script for (re-)generating the config from the template plus from the properties in settings.yml (i.e., ustreamer_janus_stun_server and ustreamer_janus_stun_port).
Notes
In the Debian postinst routine, we deliberately delegate to a privileged script instead of just inlining the logic (like we do for writing the app settings, for example), since we want to re-use the configure-janus logic in the backend in a later step.
Later, when calling the configure-janus privileged script from the backend, we also need to restart the uStreamer and Janus systemd services manually. To me, it felt safer and more explicit to let the caller take care of that, instead of making the service restart part of configure-janus. I also wasn’t sure we should be issuing direct calls to systemctl or /usr/sbin/service anyways during the Debian install procedure, instead of using deb-systemd-invoke.
I debated whether we should add a comment above the nat {} block in the Janus config, however, I wasn’t sure whether a generic explanation of what STUN is would add enough value.
Since neither ustreamer_janus_stun_server nor ustreamer_janus_stun_port do have default values, it doesn’t make sense to list them in settings.py. We currently don’t have an authoritative place anymore that lists and documents all supported properties in settings.yml, so the two newly added STUN properties are implicit and undocumented now. I have opened https://github.com/tiny-pilot/tinypilot/issues/1573 for tracking that, since I think this is a broader issue.
A few more things on testing:
I have tested this PR quite a bit on device with the latest bundle build off af5ec0d, so if you like, I’d suggest that a brief spot-check QA on your end would suffice.
Please note that testing this PR is only about verifying that we generate a valid Janus config according to the documentation, not about actually verifying the STUN mechanism itself, as the setup for that is quite complex and laborious. We already gathered enough evidence that Janus with STUN in itself does the job, and solves the use-case scenarios we are after.
We have an issue where Janus would fail to come up right after booting, if a STUN server is specified. We’ll fix this separately.
Part of https://github.com/tiny-pilot/tinypilot/issues/1460.
This PR templatizes the Janus main config file, and adds a privileged script for (re-)generating the config from the template plus from the properties in
settings.yml
(i.e.,ustreamer_janus_stun_server
andustreamer_janus_stun_port
).Notes
postinst
routine, we deliberately delegate to a privileged script instead of just inlining the logic (like we do for writing the app settings, for example), since we want to re-use theconfigure-janus
logic in the backend in a later step.configure-janus
privileged script from the backend, we also need to restart the uStreamer and Janus systemd services manually. To me, it felt safer and more explicit to let the caller take care of that, instead of making the service restart part ofconfigure-janus
. I also wasn’t sure we should be issuing direct calls tosystemctl
or/usr/sbin/service
anyways during the Debian install procedure, instead of usingdeb-systemd-invoke
.nat {}
block in the Janus config, however, I wasn’t sure whether a generic explanation of what STUN is would add enough value.ustreamer_janus_stun_server
norustreamer_janus_stun_port
do have default values, it doesn’t make sense to list them insettings.py
. We currently don’t have an authoritative place anymore that lists and documents all supported properties insettings.yml
, so the two newly added STUN properties are implicit and undocumented now. I have opened https://github.com/tiny-pilot/tinypilot/issues/1573 for tracking that, since I think this is a broader issue.A few more things on testing:
af5ec0d
, so if you like, I’d suggest that a brief spot-check QA on your end would suffice.