Earlier today I setup a jitsi server following the tutorial on Linode's YT channel and right now the URL leads to a page that says 'Welcome to Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts. Italian Schools Using WeSchool Platform Based on 8×8’s Jitsi for Distance Learning. LangSciPress @LangSciPress Somewhat unexpected, but we now run our own videoconferencing software, #Jitsi It is 100% privacy friendly, 100% open source and runs on our own servers.
After successfully experimenting with a Linode Nanode for a jitsi server I needed a new project. I chose to give Linode Object Storage a try and integrated it for external media and downloads with a download manager plugin in WordPress.
- Jitsi, on the other hand, works perfectly though there is a small yellow box that warns me that I should use a 'fully supported browser' Certhas 11 months ago. We use the Zoom standalone mostly. So Firefox isn't involved in the Zoom side. (Linode seems to be at 10$ / TB). Capableweb 11 months ago.
- Tags: Amazon audio datacenter debian digitalocean jamulus jitsi Linode low latency ping vultr 7 thoughts on “Jamulus and Temporally Hyper-Near Servers” Al Udell July 19, 2020 at 2:01 pm.
Linode Object Storage
Object Storage is a flat rate of 5$ per month and includes 250 GB. Inbound data transfer isn’t counted and 1 TB of outbound traffic is included (additional GB are 0.01$).
Setting up Object Storage in Linode Manager is remarkably easy. Basically you just add a bucket, give it a name and chose a region for the data center to be used. Of course I used Frankfurt to keep all data in Germany. On the second page you can easily generate access keys.
The bucket names in a cluster (region) are unique. Objects have got an individual URL in the format
I use ForkLift as my transfer client of choice and it’s super easy to add Linode’s Object Storage as an AWS S3 connection. The buckets then appear as folders.
Per default every object is private, but permissions can be changed easily. To make objects publicly accessible, the read permission for “Others” needs to be set. On other clients this might be called “Everyone”.
Signed URLs can be created to grant time limited access to a private object by utilising a designated access key. This just appends a key to the objects URL in the format of
These cannot be generated in Linode Manager, sadly. The CLIs of Linode and s3cmd can be used. I didn’t get lucky to get the Linode CLI to install/work properly, but since there was an alternative I didn’t bother more than two seconds. Installing s3cmd with homebrew was easy and generating a key by following Linode’s instructions worked.
I don’t have a use case for this at the moment, but it’s nice to try it and to know I could utilise signed URLs if I ever need them.
I used integration in the title, but that’s maybe too big of a word. Since every file is available with a URL, you just point your media towards it.
That’s basically it. To test all of this, I made a Super Secret Test Page and added some media. Everything works as expected with the integrated image and video blocks.
Useful Download links
I also wanted to offer download links with a preferably nice download button. This caused some frustration because using the integrated “Button” block causes e. g. images to be opened inside the browser.
The “File” block can’t be used because it only works with local files.
I tried several download manager plugins: WordPress Download Manager, Simple Download Manager, Download Monitor, Easy Media Download, Download Attachments. The only one that is simple enough for what I want and where the download links actually work as expected is Download Monitor by Never5.
Download Monitor has several style options, which can be altered with custom templates. It also counts and logs downloads, but importantly can be configured to anonymise IP addresses, which I of course configured immediately. I don’t care who you are. That’s none of my business.
For now, I use the built-in “Button” template. I like this one because it shows additional information: file name, a counter, and most importantly the file size. The button scales nicely to the post width, even on mobile devices.
The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.
Jitsi Meet is an open source video-conferencing application based on WebRTC. A Jitsi Meet server provides multi-person video conference rooms that you can access using nothing more than your browser and provides comparable functionality to a Zoom or Skype conference call. The benefit of a Jitsi conference is that all your data only passes through your server and the end-to-end TLS encryption ensures that no one can snoop on the call. With Jitsi you can be sure that your private information stays that way.
In this tutorial, you will install and configure a Jitsi Meet server on Ubuntu 20.04. The default configuration allows anyone to create a new conference room. This is not ideal for a server that is publicly available on the internet so you will also configure Jitsi Meet so that only registered users can create new conference rooms. After you have created the conference room any users can join as long as they have the unique address and the optional password.
Before you begin this guide you’ll need the following:
- One Ubuntu 20.04 server set up by following the Initial Server Setup with Ubuntu 20.04 tutorial, including a non-root sudo-enabled user. The size of the server you will need mostly depends on the available bandwidth and the number of participants you expect to be using the server. The following table will give you some idea of what is needed.
- A domain name configured to point to your server. You can learn how to point domains to DigitalOcean Droplets by following the How To Set Up a Host Name with DigitalOcean tutorial. Throughout this guide, the example domain name
When you are choosing a server to run your Jitsi Meet instance you will need to consider the system resources needed to host conference rooms. The following benchmark information was collected from a single-core virtual machine using high-quality video settings:
|Two Participants||3%||30Kbps Up, 100Kbps Down|
|Three Participants||15%||7Mbps Up, 6.5Mbps Down|
The jump in resource use between two and three participants is because Jitsi will route the call data directly between the clients when there are two of them. When more than two clients are present then call data is routed through the Jitsi Meet server.
Log in to your server as the non-root, sudo-enabled user before starting Step 1.
Step 1 — Setting the System Hostname
In this step, you will change the system’s hostname to match the domain name that you intend to use for your Jitsi Meet instance and resolve that hostname to the localhost IP,
127.0.0.1. Jitsi Meet uses both of these settings when it installs and generates its configuration files.
First, set the system’s hostname to the domain name that you will use for your Jitsi instance. The following command will set the current hostname and modify the
/etc/hostname that holds the system’s hostname between reboots:
The command that you ran breaks down as follows:
hostnamectl: A utility from the systemd tool suite to manage the system hostname.
set-hostname: Sets the system hostname.
Check that this was successful by running the following:
This will return the hostname you set with the
Next, you will set a local mapping of the server’s hostname to the loopback IP address,
127.0.0.1. Do this by opening the
/etc/hosts with a text editor:
Then, add the following line:
This local mapping of your Jitsi Meet server’s domain name to
127.0.0.1 is important because your Jitsi Meet server uses several networked processes on your server that accept local connections on the
127.0.0.1 IP address from each other. These connections are authenticated and encrypted with a TLS certificate, which is registered to your domain name. Locally mapping the domain name to
127.0.0.1 makes it possible to use the TLS certificate for these local network connections.
Your server now has the hostname that Jitsi requires when installed. In the next step, you will open the firewall ports that are needed by Jitsi and the TLS certificate installer.
Linode Jitsi Meet
Step 2 — Configuring the Firewall
When you followed the Initial Server Setup with Ubuntu 20.04 guide you enabled the UFW firewall and opened the SSH port. The Jitsi server needs some ports opened so that it can communicate with the call clients. Also, the TLS installation process needs to have a port open so that it can authenticate the certificate request.
The ports that you will open are the following:
80/tcp: Port used in the TLS certificate request.
443/tcp: Port used for the conference room creation web page.
10000/udp: Ports that will transmit and receive the encrypted call traffic.
Run the following
ufw commands to open these ports:
Check that they were all added with the
ufw status command:
You will receive the following output if these ports are open:
The server is now ready for the Jitsi installation, which you will complete in the next step.
Step 3 — Installing Jitsi Meet
In this step, you will add the Jitsi stable repository to your server and then install the Jitsi Meet package from that repository. This will ensure that you are always running the latest stable Jitsi Meet package.
First, download the Jitsi GPG key with the
wget downloading utility:
apt package manager will use this GPG key to validate the packages that you will download from the Jitsi repository.
Next, add the GPG key you downloaded to
apt’s keyring using the
You can now delete the GPG key file as it is no longer needed with this command:
Now, you will add the Jitsi repository to your server by creating a new sources file that contains the Jitsi repository. Open and create the new file:
Add this line to the file for the Jitsi repository:
Save and exit the editor.
Finally, perform a system update to collect the package list from the Jitsi repository and then install the
During the installation of
jitsi-meet you will be prompted to enter the domain name (for example,
jitsi.your-domain) that you want to use for your Jitsi Meet instance.
Note: You move the cursor from the hostname field to highlight the <OK> button with the
TAB key. Press
ENTER when <OK> is highlighted to submit the hostname.
You will then be shown a new dialog box that asks if you want Jitsi to create and use a self-signed TLS certificate or use an existing one if you have one:
If you do not have a TLS certificate for your Jitsi domain select the first, Generate a new self-signed certificate, option.
Your Jitsi Meet instance is now installed using a self-signed TLS certificate. This will cause browser warnings so you will get a signed TLS certificate in the next step.
Step 4 — Obtaining a Signed TLS Certificate
Jitsi Meet uses TLS certificates to encrypt the call traffic so that no one can listen to your call as it travels over the internet. TLS certificates are the same certificates that are used by websites to enable HTTPS URLs.
Jitsi Meet supplies a script to automatically download a TLS certificate for your domain. Run this certificate installation script provided by Jitsi Meet at
/usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh with the following command:
Radha also known as gopi, the lover and the most represented companion of krishna. Radha is also considered as the avatar of laxmi, just like krishna is considered an avatar of vishnu. Radha and krishna is a symbol of divine love, which connects a living being to. Radha krishna photo amazon. With Krishna, Radha is acknowledged as the Supreme Goddess, for it is said that she controls Krishna. It is believed that Krishna enchants the world, but Radha 'enchants even Him. Therefore She is the supreme goddess of all Wikipedia. A high quality photo print on archival acid free paper 150g. Perfect for framing. Find the biggest selection of Poster Frames from Generic at the lowest prices.
The script prints the following information when you run it and asks you to supply an email address:
This email address will be submitted to the certificate issuer
https://letsencrypt.org and will be used to notify you about security and other matters related to the certificate. You must enter an email address here to proceed with the installation.
The script will complete the installation and configuration of an SSL certificate for your Jitsi server without needing any more user input.
The default configuration for Jitsi Meet is that anyone visiting your Jitsi Meet server homepage can create a new conference room. This will use your server’s system resources to run the conference room and is not desirable for unauthorized users. In the next step, you will configure your Jitsi Meet instance to only allow registered users to create conference rooms.
Step 5 — Locking Conference Creation
In this step, you will configure your Jitsi Meet server to only allow registered users to create conference rooms. The files that you will edit were generated by the installer and are configured with your domain name.
jitsi.your_domain will be used in place of a domain name in the following examples.
/etc/prosody/conf.avail/jitsi.your_domain.cfg.lua with a text editor:
Edit this line:
This configuration tells Jitsi Meet to force username and password authentication before allowing conference room creation by a new visitor.
Then, in the same file, add the following section to the end of the file:
This configuration allows anonymous users to join conference rooms that were created by an authenticated user. However, the guest must have a unique address and an optional password for the room to enter it.
Here, you added
guest. to the front of your domain name. For example, the correct name to put here for
guest. hostname is only used internally by Jitsi Meet, you will never enter it into a browser or need to create a DNS record for it.
Open another configuration file at
/etc/jitsi/meet/jitsi.your_domain-config.js with a text editor:
Edit this line:
Again, using the
guest.jitsi.your_domain hostname that you used previously. This configuration tells Jitsi Meet what internal hostname to use for the un-authenticated guests.
And add the following line to complete the configuration changes:
This configuration points one of the Jitsi Meet processes to the local server that performs the user authentication that is now required.
Your Jitsi Meet instance is now configured so that only registered users can create conference rooms. After a conference room is created, anyone can join it without needing to be a registered user. All they will need is the unique conference room address and an optional password set by the room’s creator.
Now that Jitsi Meet is configured to require authenticated users for room creation you need to register these users and their passwords. You will use the
prosodyctl utility to do this.
Run the following command to add a user to your server:
The user that you add here is not a system user. They will only be able to create a conference room and are not able to log in to your server via SSH.
Finally, restart the Jitsi Meet processes to load the new configuration:
The Jitsi Meet instance will now request a username and password with a dialog box when a conference room is created.
Your Jitsi Meet server is now set up and securely configured.
In this article, you deployed a Jitsi Meet server that you can use to host secure and private video conference rooms. You can extend your Jitsi Meet instance with instructions from the Jitsi Meet Wiki.