Self-Hosting with existing multi-host webserver?

I tried to go through the Self-Hosting Guide and it is not working. I have running my own Ubuntu server for a while. I have several web systems running on it through apache virtual hosts. I already have HTTPS working via a valid cert.

My main host is opencalaccess.org.

Originally I tried creating a new host, meet_.opencalaccess._org, and added it to my /etc/hosts file. This horked several things in my system. Crontab jobs quit working. I am still not getting most crontab e-mails.

I have got rid of that host and am trying to use opencalaccess._org. The “apt install jitsi-meet” works without errors. I changed the values in the /etc/systemd/system.conf file.

My web page at opencalaccess._org is still working. But jitsi is … where?

I am seeing errors like:

Jicofo 2020-11-21 17:39:05.792 SEVERE: [39] org.jitsi.impl.protocol.xmpp.XmppProtocolProvider.log() Failed to connect/login: javax.net.ssl.SS
LHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderE
xception: unable to find valid certification path to requested target
org.jivesoftware.smack.SmackException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building fai
led: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1076)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:1000)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1016)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.c

It is saying it cannot connect to auth.opencalaccess.org. Yes, because I did not create that. Where is that coming from?

I am sure I am doing something stupid on my server. I know how to use a hammer on my Ubuntu server and I nail things on ok, but I am not an expert.

first, what you are trying to do is not at all typical use for a video conferencing server. The typical use covered by the Jitsi docs is a VPS dedicated to videoconferencing. Why is it so ? because most home deployments don’t have the necessary bandwidth for even a moderate use, and because existing web servers on VPS are typically sized for web use, that is, not for a real time server; these servers don’t have the necessary bandwidth, raw CPU power - all that is necessary for a video server is not for a web server.
So before solving this somewhat complicated problem - compounded by the fact that you use Apache while Jitsi project is using Nginx (it’s the most used http server now -.take the time to consider if your setup has the necessary requirements to handle the load you want to serve.

In short, what you are trying to do is not easy and the Jitsi project has no actual need to make it easy, it’s outside the project’s goals - when the target is serving thousands of video users, serving also other web sites is not worth the bother, it’s even a hindrance to scaling.

this is a prosody site. You don’t have to create them in the web server sites. In the Jitsi configuration, the web server is proxying to prosody (/http-bind -> localhost:5280)

IMO the 3 main problems are:

  1. by default Jitsi project is managing Let’s Encrypt certificates and you don’t want that, so you have to somehow disable this. I don’t see how the default Jitsi setup could disable existing cron jobs, but certainly if you ask Jitsi to manage Let’s Encrypt certiificates while you are managing them yourself, results will not be pretty
  2. Jitsi default install is handling the web server configuration, that is tested and working fine with a fresh web server installed by Jitsi, but interfering with an existing config is a minefield, certbot (the tool used by Jitsi to handle Let’sEncrypt certiificate) had tons of problems with that. Programmatically managing text configurations is very difficult if there are manual configurations already done because the imagination of sysadmins is endless and exceed the ingenuity of software developers and there is no standard on text configuration files formats.
  3. the Jitsi setup relies on adressing by room, that is, you can use url/room1, url/room2, … and this is tripping constantly the people who want to use url schemes, that is, you have something like
    https;//mysite.com/jitsi/
    Instead, most (like 99,9%) existing jitsi sites are adressed like this;
    https://jitsi.mysite.com
    becausei it’s much easier to handle this problem.
    I think it’s possible to use the Apache sysadmin preferred way, but it’s not so easy. I think I have seen on this forum some posting about this topic. Good luck.

This all makes a lot of sense. You are right that it does not make sense to try to run this on the system I have here. Much thanx.

  • ray

I’m inclined to defer to people who know jitsi inside and out. However I experienced some of the same issues as described by RayKiddy and can offer a few insights that might be helpful.

My setup includes a jitsi server as well as a website served by nginx, running on a VPS with 4GB ram and 4 cores. URLs are meet.mydomain.com (for jitsi) and mydomain.com as the website host.

Getting everything to play nice with each other was a bit of a challenge. Fortunately the standard install directions covered the major elements. If the website is already configured in nginx to use TLS (443) the installation scripts take that into account. (Jitsi virtual host also listens on 443.)

The biggest question was how to set up the letsencrypt certs to accommodate jitsi and the web host. After trying different approaches the best and simplest was running certbot naming all hosts on the command line starting with meet.mydomain.com, then mydomain.com, etc. certbot automatically adds the domain names to the “subject alternative name” section of the certificate. This “multi-host” certificate works as long as the jitsi server domain is listed first.

It’s indeed the case that jitsi is by far the heaviest user of resources on the VPS host. Since the web server is a much lighter user no contention has been evident. Naturally it’s essential that each virtual host has its own DNS record but I think that’s covered in the general install instructions.

I don’t see this restriction myself - and I can’t imagine why it would exist.

At the time I was setting up it up it was the simplest solution. Jitsi programs look for certs in “/etc/letsencrypt/live/meet.mydomain.com”. Certbot creates this directory with symlinks to pem files when first run.

The directory is named after the primary domain given to certbot. When several domains are given to certbot it uses the first as primary. Names in the SAN section of the cert are listed in this order.

Perhaps laziness on my part, but I wanted the related domains on the same cert but that meant the “meet…” subdomain had to be primary in order to satisfy jitsi.

In retrospect I could have set up separate certs for subdomains. I may yet do that if I add new domains to the host in the future.

You may have a different perspective on organizing multiple domains on a host running jitsi. If you do, I’m interested, always things for me to learn.

I’m utterly failing in following your thinking ;-).
If I take a Jitsi site on the late and lamented Jitsi wiki, for a random pick: here , you’ll see on the certificate that the jitsi site is NOT the first on the Certificate Subject Alt Name.