This uses nginx' server-side includes, so each domain configured by
`__jitsi_meet_domain` can have its own customisation.
Note that the file customisation file must exist for each domain,
`__jitsi_meet_domain` takes care of that already.
Sponsored by: camilion.eu, eXO.cat
The escaping issue was overlooked because it was in a comment block; it wasn't
relevant.
No functional changes intended.
Sponsored by: camilion.eu, eXO.cat
By using https://gitlab.com/mfmt/jsi which consists of very small and simple
static files, we enable interpretations by default.
With this commit, any DOMAIN created with __jitsi_meet_domain will serve jsi on
https://DOMAIN/i/ and any ROOM can be used with simultaneous interpretation on
https://DOMAIN/i/ROOM
Sponsored by: camilion.eu, eXO.cat
While there, make things a tad easier to maintain.
Note that in this version, jitsi switches to using nginx upstreams; it shouldn't
be relevant for instances fully managed with these types.
Sponsored by: camilion.eu, eXO.cat
This is a backwards-compatible change.
We switch the approach from "treat all domains as if they were the main domain"
to: "each domain has its own prosody settings".
This works perfectly fine, even with secured domains.
There is a caveat with secured domains, in that they use the main domain to log
in; this means that users are shared across all domains (as they were before
this commit).
This is due to jicofo refusing to start meetings from a domain that is not
configured, and it only accepting one domain.
Right now, this is acceptable, however we could want to authenticate against
e.g. different LDAP / IMAP servers in the future, so this would need addressing
at that stage.
Probably the best way to solve it is by patching jicofo, so it accepts starting
conferences from multiple domains and getting that patch upstream.
Sponsored by: camilion.eu, eXO.cat
with this, admins can take advantage of e.g. matomo to have some usage
statistics.
The parameter defaults to `disabled: true`, which is the most privacy-friendly!
Sponsored by: camilion.eu
This is done with slight adaptations from the official guide at
https://jitsi.github.io/handbook/docs/devops-guide/secure-domain
Amongst other changes, we rely on Prosody's configuration parser only overwriting the parts of a VirtualHost that are explicitly specified in "later appearing" (lexicographically speaking) files.
This allows us to let Jitsi manage the main config file and adding the few customisations on top of it.
We also use the Plaintext authenticator as this is enough atm and is the easiest to manage in an idempotent fashion; support for other authentication mechanisms is possible, see Prosody's documentation for that.