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 enables us to setup smaller jitsi instances that work reliably.
We set 3 threshholds:
- < 3G RAM: use 0.75G max memory
- < 5G RAM: use 1G max memory
- < 8G RAM: use 2G max memory
- >= 8G RAM: use 3G max memory (jitsi's default)
For more information as to why and how this is done, see:
https://gitlab.com/guifi-exo/projectes/-/issues/318https://github.com/jitsi/jitsi-meet/issues/6589
as investigated back in the day by @pedro
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
Closes#14 by committing to keeping the package up to date as promptly as
possible; else weird things happen and there are no real good solutions for
this. E.g. we have seen in the past that due to security issues, a jitsi
dependency needs to be upgraded, but some package that jitsi-meet depends upon
also has an upper limit on that package's version.
A note was added to the manpage in order make it explicit that maintenance of
this type can be sponsored to ensure its proper functioning.
Closes#15 by using `__file`. This will also allow us to have more control over
jicofo's settings, which might be important when we start doing recordings.
Sponsored by: lafede.cat
Since nginx package version v1.10.1-r3, Alpine packagers have changed
the default vhost directory from conf.d to http.d [0]. This reflects
this change.
[0]: alpine package commit 383ba9c0a200ed1f4b11d7db74207526ad90bbe3
While adding FreeBSD support to the type I noticed various issues:
- We were making sure that the KeyTable and SigningTable were created in
__opendkim_genkey, but that was being done with the default cdist permissions
(0400) which could result in issues when reloading the service after privilege
drop.
This is addressed by checking that it exists/creating it in __opendkim (just
once, not once per __opendkim_genkey call) with laxer permissions (0444).
- In __opendkim, the service was being started after the config file was
installed. This is insufficient as OpenDKIM will refuse to start with the
generated config if either SigningTable or KeyTable do not exist yet.
- __opendkim_genkey had the implicit assumption that the --directory parameter
always ended in a slash. This was not documented and error-prone; we are now
a bit laxer and add the trailing slash if it is missing.
- __opendkim_genkey was not changing permissions for the resulting .txt file.
This was not critical for it to function, but it was inconsistent.
- As documented in #17, __opendkim allows for a --userid parameter that might
cause issues with keys generated by __opendkim_genkey.
This issue has not been addressed yet, but I recommend deprecating the
--userid parameter.
