Installation/configuration of Jitsi and Jibri improvement suggestions

Install & Config
#1

So, I’ve been working with Jitsi for about 2 weeks and I’ve been trying to setup something robust and simple. But by design this seems quite a challenge.

Docker

The Docker solution works kinda great! However, the downside is that it’s Docker. Which has poor IPv6 support. And to customize configs I have to create a Docker overlay on top of the official images. That’s needed for e.g. theming. Most other things are setup through the .env and works great. But the downside for me is that I want to use a reverse proxy, which has drawbacks.

Package install

After installing the packages, it seems I have to change configs that are either managed or generated by these packages. That goes against usual Linux config management by packages. Usually there are configs that you shouldn’t touch, because they will be replaced by package updates. When custom changes are needed, then you can add configs with a suffix like e.g. .custom to override settings. Or use configs in /etc/default or /etc/sysconfig to set certain custom variables or switches.

But with Jitsi I get the impression that all custom settings may be gone after upgrading the packages. The config /etc/prosody/conf.avail/YOUR_FQDN.cfg.lua is auto generated, and also contains TLS settings. Will those settings be overwritten at an update as well? I hope so, to keep in sync with the latest security requirements :slight_smile: But at the same time, that config file needs to be customized for e.g. authentication, among other files.

Jibri is even “worse” (please don’t get me wrong, this is not a rant, I’m a huge fan of your work). It has a package, but it seems a lot of manual work is needed after that: Set Up Jibri for Jitsi Recording/Streaming – Nerd on the Street

Some of it needs to be manually updated as well (Chrome driver). Well, it looks easily automated in Ansible of course, so there are solutions, but it’s still kinda odd.

Is there any official documentation about theming and installing Jibri?

Conclusion

So in conclusion, it seems that the installation procedure for both Docker and deb packages have up and downsides. But they both share the downside that there is no separation between custom files (for e.g. themes) and custom configs.

Every update will probably overwrite everything. Ansible might help, but also to replaces lines it’s often needed to specify where the line is placed. For example with a regex and then define that it should be placed after that match. But if config files change with an update, then this may break too.

So to end with a question: Are there plans to enable more fine grained customization without touching package managed files? Or is my whole conclusion wrong here? That may also be the case of course :slight_smile:

#2

Nope.

There is nothing to theme in jibri as it uses the same web client code as the normal clients.

Yeah Jibri is not so easy to setup, but also automating this in the package also is not easy as there are many system changes that need to happen including the manual process of having the correct kernel version.

Well the only file that is making problem and I know of is interface config, and that file is deprecated and we will remove it over time, but even that file you can override with an nginx location setting as the config file and have it in your /etc folder with customized values so it will not be overwritten.

There are also other files there that you can override the same way in which you can put custom stuff, like base.html, body.html, head.html, plugin.head.html, title.html.

There is a lot of work done to be able to have a customized and upgradeable system (I’m talking for the debian packages as I don’t have experience with Docker and cannot talk about it).

#3

Thanks for your reply! You answered “nope” at my question if customized files are overridden when upgrading a package. In that same sentence I also state that it should be overridden, because some of those files contain TLS configurations. If those are never upgraded to newer standards, then a configuration drift will arise after some time. Because hopefully upstream keeps an eye out on using the best ciphers, so those TLS options need to be updated. But when they are, custom configs are lost.

There is a lot of work done to be able to have a customized and upgradeable system

Maybe have a look at the systemd approach. In /usr/systemd are all the system managed files, those shouldn’t be touched. If someone wants to override it, then they should use /etc/systemd. The files loaded in /etc/systemd override anything from /usr/systemd which bears the same name and path (the only difference is the parent dir /etc or /usr).

Or add something like /etc/default/jitsi, which then has something similar to the .env file in Docker. Where you can set RECORDING=true or THEME_DIRECTORY=/var/jitsi/custom_theme. Where the recording variable is used by the lua scripts to enable or disable the recording. Now I have to edit the lua scripts, which are used as “config files”. Using scripts as config files is I think part of the problem. And the theme directory variable may be used to point to a different directory where people can then put their custom logos, CSS, favicon, etc.

Just some thoughts. Again, I’m very thankful that Jitsi exists and I truly support your efforts.

I’ll weigh the pros and cons of both setups and then choose one, this weekend or the next. But both are troublesome in the current setup to maintain over a long period of time.

#4

The general rule is that once the files got to /etc/ we do not touch them as people may have custom settings and we cannot modify/drop them on every update.
There are cases though, security issues that we do update them, with as simple as possible modifications there was a turnserver config I remember we did an year go … so we do take security issues seriously.

Yes there are many approaches for solving every config, and we want to have them all, but we also don’t have all the time and resources of the world. So in other words we take contributions, so anything you think can be done better and will help you and the other users and you don’t break existing deployments … any PRs are welcome.

Thank you.

1 Like