I would like to install jitsi-meet on a LAN, to use it on a classroom. Why would I want to do this? Because of screen sharing. I would like to share my screen with the students. This is very useful for example when teaching programming (especially when there is no projector).
Another useful feature is the chat. I can send students url-s that they can open (served from local servers, for example from my computer).
I tried to install it on a VirtualBox machine (built and managed with vagrantup). I forwarded the ports 443, 4443 and 10000 to the virtual machine, I disabled HSTS on apache configuration, etc. However couldn’t make it work.
Is it possible to make it work locally? If yes, how?
Or if you think that using jitsi just for desktop sharing and local chat on a LAN is overkill, what would you suggest to use?
This can be done. No it is not an overkill, but mind that running it on a desktop station is not a good idea, as today most of the desktop stations use wifi, make sure it is wired. And make sure the AP for the wifi the students use is good enough. Cause 20-30 people joining from the same AP in a video conference can the AP can be easily blown. Yo are in case where there should not be much traffic it may be ok, but saying it cause I have seen this in a classroom
By default VM run in NAT environment, had you set to jvb its internal and external address?
When I install it locally, I add something like this on /etc/hosts: “127.0.0.1 meet.example.org” and it does not even need the NAT fix. I can open https://meet.example.org on the browser and it works fine.
The problem is that when I try something like https://192.168.0.233/ or https://192.168.0.233:8443/ (where 8443 is forwarded to 443) it does not work. In a LAN it cannot be used with a fake name that I have added on /etc/hosts, it has to be accessed from the IP.
There is a way to config it with nginx. You need to make sure your config.js generates bosh different address that depends on the link you used, I recently posted the config in another thread, need to find it.
You are right. If it finds apache2 installed it configures apache2, if it finds nginx it configures nginx.
But I still don’t get how to fix the configuration of nginx so that it works both with a domain name (something like meet.example.org) and an IP (something like 192.168.0.10, or even 127.0.0.1).
I understand that this is not a jitsi-meet issue but rather an apache2/nginx configuration issue, however I still have to find out how to fix it.
I works with a fake domain like meet.example.org, if I add to /etc/hosts a line like: 127.0.0.1 meet.example.org
The use case that I am thinking about is this:
I am in a room (or classroom) with a few other people, each of them having a laptop. I start a hotspot on my laptop (like this: https://gitlab.com/docker-scripts/desktop/blob/master/misc/hotspot.sh#L26) Then I start a jitsi-meet container on my laptop and invite the other to connect (probably with an IP like 10.42.0.1). Then I can use screen sharing of jitsi-meet to share my screen with the other people. We can all block audio and video since it is not needed in this case (we are all present on the same room).
Actually this is a corner case, not quite frequent or useful, since I want to do this because I don’t have a projector (otherwise I can share my desktop using the projector). So it is not such a big issue if it does not work.
Now that I think about it, since I am starting my own hotspot on my laptop and the other people are connecting to it, maybe I can start a dnsmasq service as well and let them resolve meet.example.org to the IP that I want (in this case 10.42.0.1), and this would make everything work.
So, it seems that this is not such a big issue after all, even if it is not solved.
Thanks for your help and support.
Im using latest chrome and I’m using http connection instead of https because it’s in my local network. I have added two systems to my LAN. My server is running jitsi docker and my .env looks like below,
# Basic configuration options
# Directory where all configuration will be stored.
# Exposed HTTP port.
# Exposed HTTPS port.
# System time zone.
# IP address of the Docker host. See the "Running on a LAN environment" section
# in the README.
# Let's Encrypt configuration
# Enable Let's Encrypt certificate generation.
# Domain for which to generate the certificate.
# E-Mail for receiving important account notifications (mandatory).
# Basic Jigasi configuration options (needed for SIP gateway support)
# SIP URI for incoming / outgoing calls.
# Password for the specified SIP account as a clear text
# SIP server (use the SIP account domain if in doubt).
# SIP server port
# SIP server transport
# Authentication configuration (see README for details)
# Enable authentication.
# Enable guest access.
# Advanced configuration options (you generally don't need to change these)
# Internal XMPP domain.
# Internal XMPP domain for authenticated services.
# XMPP domain for the MUC.
# XMPP domain for the internal MUC used for jibri, jigasi and jvb pools.
# XMPP domain for unauthenticated users.
# Custom Prosody modules for XMPP_DOMAIN (comma separated)
# Custom Prosody modules for MUC component (comma separated)
# Custom Prosody modules for internal MUC component (comma separated)
# MUC for the JVB pool.
# XMPP user for JVB client connections.
# XMPP password for JVB client connections.
# STUN servers used to discover the server's public IP.
# Media port for the Jitsi Videobridge
# TCP Fallback for Jitsi Videobridge for when UDP isn't available
# A comma separated list of APIs to enable when the JVB is started. The default is none.
# See https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest.md for more information
# XMPP component password for Jicofo.
# XMPP user for Jicofo client connections. NOTE: this option doesn't currently work due to a bug.
# XMPP password for Jicofo client connections.
# XMPP user for Jigasi MUC client connections.
# XMPP password for Jigasi MUC client connections.
# MUC name for the Jigasi pool.
# Minimum port for media used by Jigasi.
# Maximum port for media used by Jigasi.
# Disable HTTPS. This can be useful if TLS connections are going to be handled outside of this setup.
# Redirects HTTP traffic to HTTPS. Only works with the standard HTTPS port (443).
I have tried by uncommenting DISABLE_HTTPS=1 flag but the result is same. Do I missing anything in this .env file.?