anyone set up a jitsi server?
Phil Marsh
microcraftx at gmail.com
Tue May 14 20:37:00 UTC 2024
Hi Bob,
I was able to get Jitsi working on my machine! And I was able to hold a
meeting. This is that HP740 thin client machine which is so low-power it
will always be left on to provide a gateway to the rest of my systems.
I think that initially, I had a bad ssl cert(s). I install them manually
since I want to download just one certificate for all my systems.
While I greatly admire and appreciate open-source contributors, the only
real major fault I see with a lot of open-source software is the difficulty
in diagnosing problems. I'm not a network engineer, but rather a noob and
network, certificate issues are complex for me as I'm still learning this.
Good diagnostic messages could make this so much easier and I wouldn't
think that would require that much extra code?
If/when I get involved with open-source I promise myself to be anal about
including diagnostics for the users.
In other news, I'm busy setting up my four-node compute system and it
appears that CSU surplus is a great source of cheap RAM. Yea, it's not
state-of-art but my EPYCs top out at 2666MHz DDR4 anyway and it seems there
is very little difference in 2400MHz RAM and 2133MT RAM in terms of my
initial benchmarks. This could be due to the 2133MT RAM's CL of 15 vs. that
of the 2400MT RAM CL=19. But I will need to bench it with my actual
applications to be sure. I'm still trying to understand the performance
implications of MT vs CL and few people online can explain this cogently. I
suspect that CL/MT is the latency time to start the fetching or writing to
RAM and if one is writing or fetching a series of sequential locations, the
MT dominates because the CL time applies only to the first write or fetch?
Why is this so hard for people to explain clearly?
Oops I shouldn't have let the secret out! Slowly stuffing this system and I
have 256GB in one node already. Will try to get another node to 512GB for
those really big electromagnetic simulations. Will be exciting to turn this
four-headed beast loose on these!
If you need help with this, I'll be glad to help,
Best,
Phil
On Wed, May 8, 2024 at 2:10 PM Bob Proulx <bob at proulx.com> wrote:
> Hi Phil,
>
> Phil Marsh wrote:
> > I'm trying to set up jitsi but the instructions appear not to work.
> > It just keeps disconnecting me when I try to log in.
> > Anyone have any luck with setting it up?
>
> I have set it up from scratch. A few times. Because my experience is
> that you can't upgrade a jitsi server. You can only set one up from
> scratch. If for any reason along the installation journey there is a
> problem then you can only discard the virtual machine, create a new
> pristine one, and then install for the first time again. It's a
> problem!
>
> I will provide my notes on setting up Jitsi but first will say that
> for last weekend's LibrePlanet the FSF decided not to use Jitsi but
> switched to using Galene instead. Among other things it is simpler
> and handles a high load of use better than Jitsi. You might check out
> Galene and see if it works better for you. However having said that I
> haven't myself set up Galene yet.
>
> https://galene.org/
>
> My notes for setting up Jitsi follow. I am always installing this in
> a VM so that I can discard the VM and start again easily. Because
> Jitsi is very rigid. Rigid means fragile. Anything changes and the
> entire Jitsi system just fractures into breakage. So I only ever
> install Jitsi for the first time on a new server. That could be a
> container okay too.
>
> First I do a bunch of routine setup for the system. And also install
> nginx and set up https certificates via Let's Encrypt using the simple
> dehydrated client. I get all of that set up first. Then this. My
> notes reference jitsi.member.fsf.org because that is the system I am
> setting up but change that to be the name of your system.
>
> #!/bin/sh
>
> # The goal of this script is to automate and document by this
> # automation the setup of Jitsi on the system.
> #
> # Copyright 2023 Bob Proulx <bob at proulx.com>
> #
> # Licensed under the Apache License, Version 2.0 (the "License");
> # you may not use this file except in compliance with the License.
> # You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
>
> ################################################################
> # Jitsi Setup
>
> # Jitsi wants the hostname to be a FQDN like in the BSD side of the
> # world and not a short name as is standard in the Trisquel, Mint,
> # Ubuntu, Devuan, Debian, part of the world.
> case $(hostname) in
> *.*) : okay, has dots ;;
> *) echo "Jitsi requires hostname to be a FQDN." 1>&2; exit 1;;
> esac
>
> # Jitsi wants the /etc/hosts to bind the FQDN to the public IP address
> # and not to a loopback address. (Jitsi does not like 127.0.1.1 as is
> # typically done.) Something that will look like this following line.
> # 93.184.216.34 jitsi3p.fsf.org jitsi3p
> # Ensure this is the case in the event it was provisioned otherwise.
>
> # ip addr show will produce a line like this line
> # inet 93.184.216.34/24 brd 93.184.216.255 scope global eth0
> # Grab that line and extract the IP address from it.
> ipv4=$(ip addr show | awk '$1=="inet"&&$NF!="lo"{print$2}' | awk -F/
> '{print$1;exit}')
> # Use this IPv4 address and the hostnames to construct the desired line.
> etchostsline="$ipv4 jitsi.member.fsf.org jitsi $hostname $host"
> # Create a BRE Basic Regular Expression to look for this pattern but
> # ensure some flexibility ignoring differences of whitespace.
> etchostspattern=$(echo "$etchostsline" | sed 's/
> /[[:space:]][[:space:]]*/')
> etchostspattern=$(echo "$etchostspattern" | sed 's/\./\\./g')
> if ! grep -q "$etchostspattern" /etc/hosts; then
> if grep -q "^[[:space:]]*$ipv4[[:space:]]" /etc/hosts; then
> # The IP address is there. Edit it in place.
> sed --in-place "s/^[[:space:]]*$ipv4[[:space:]].*/$etchostsline/"
> /etc/hosts
> else
> # The IP address is not there. Append it to the end.
> echo "$etchostsline" >> /etc/hosts
> fi
> fi
> # At this point the desired line exists in /etc/hosts even if it was
> # not initially provisioned this way.
>
> # Jitsi repositores use https transport.
> debian_install apt-transport-https
>
> # Ubuntu systems need the "universe" repository available.
> # apt-add-repository universe
>
> # Setup up prosody 3rd party repository. Have we gotten the key? If
> # not then get it and install it.
> pkfile="/etc/apt/keyrings/prosody-debian-packages.key"
> if [ ! -f "$pkfile" ]; then
> curl -sL https://prosody.im/files/prosody-debian-packages.key -o
> "$pkfile"
> fi
> # Jitsi wants to use $(lsb_release -sc) to get a release name like
> # "jammy" but Trisquel 11 will produce "aramo" there. Jitsi has a
> # repository for Ubuntu Jammy but not Trisquel Aramo. Use the Ubuntu
> # Jammy name for the repo and avoid using the Jitsi scripted way of
> # using $(lsb_release -sc) to get the name.
> pdsfile="/etc/apt/sources.list.d/prosody-debian-packages.list"
> if [ ! -f "$pdsfile" ]; then
> cat >"$pdsfile" <<'EOF'
> deb [signed-by=/etc/apt/keyrings/prosody-debian-packages.key]
> http://packages.prosody.im/debian jammy main
> EOF
> fi
>
> if [ ! -f /usr/share/keyrings/jitsi-keyring.gpg ]; then
> curl -sL https://download.jitsi.org/jitsi-key.gpg.key |
> gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg
> fi
> if [ ! -f /etc/apt/sources.list.d/jitsi-stable.list ]; then
> cat >/etc/apt/sources.list.d/jitsi-stable.list <<EOF
> deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg]
> https://download.jitsi.org stable/
> EOF
> fi
>
> # Jitsi documents using lua5.2 but of course we have lua5.4 instead.
> debian_install lua5.4
>
> privkey="/var/local/dehydrated/certs/jitsi.member.fsf.org/privkey.pem"
> if [ ! -f "$privkey" ]; then
> # No certificate exists. Bootstrap one.
>
> if [ ! -f /etc/nginx/sites-available/bootstrap-https ]; then
> cat >/etc/nginx/sites-available/bootstrap-https <<'EOF'
> server {
> server_name jitsi.member.fsf.org;
> listen 80;
> listen [::]:80;
> location /.well-known { root /var/local/dehydrated/www; }
> root /var/www/html;
> index index.html index.nginx-debian.html;
> }
> EOF
> fi
> symlink ../sites-available/bootstrap-https /etc/nginx/sites-enabled/
> nginx -s reload
> # Sometimes there is a server or network error. That causes noise to
> # the cron mail. Instead retry just a little as the problems are
> # almost always transient glitches. Example of one problem.
> # ERROR: Problem connecting to server (get for
> https://acme-v02.api.letsencrypt.org/directory; curl returned with 6)
> logfile=/var/log/dehydrated/dehydrated.log
> count=3
> while [ $count -gt 0 ]; do
> count=$(($count - 1))
> # Run the dehydrated script as the user.
> su -s /bin/sh -c 'TMPDIR=/tmp dehydrated --cron' dehydrated
> >"$logfile" 2>&1
> if ! grep -q -i "^ERROR: Problem connecting to server" "$logfile";
> then
> break
> fi
> sleep 15
> done
> # Example error message logged to file:
> # ERROR: Challenge is invalid! (returned: invalid) (result: {
> if grep -q -i error "$logfile"; then
> cat "$logfile" 1>&2
> exit 1
> fi
> # It worked and we got a certificate.
> # Discard the bootstrapping config and place in the real config.
> rm -f /etc/nginx/sites-enabled/bootstrap-https
> fi
>
> exit 0
>
> At this point I have not yet automated the next setup. I have to do
> this manually at this point.
>
> apt-get install jitsi-meet
>
> When it asks about certificates choose "I want to use my own
> certificate" and provide it with the path to our let's encrypt
> certificate.
>
> ssl_certificate /var/local/dehydrated/certs/
> jitsi.member.fsf.org/fullchain.pem;
> ssl_certificate_key /var/local/dehydrated/certs/
> jitsi.member.fsf.org/privkey.pem;
>
> Configuring jitsi-videobridge2
>
> The value of the domain that is set in the Jitsi Videobridge
> installation.
> The domain of the current installation (e.g. meet.jitsi.com):
> jitsi.member.fsf.org
>
> Configuring jitsi-meet-web-config
>
> Jitsi Meet requires an SSL certificate. This installer can generate
> one automatically for your using "Let’s Encrypt". This is the
> recommended and simplest option for most installations. In the
> event you need to use a certificate of your own, you can configure
> its location which defaults to /etc/ssl/--domain.name--.key for the
> key and /etc/ssl/--domain.name--.crt for the certificate.
> If you are a developer and are only looking for a quick way to test
> basic Jitsi Meet functionality then this installer can also generate
> a self-signed certificate.
> SSL certificate
> Let's Encrypt certificates
> I want to use my own certificate <-- pick this one
> Generate a new self-signed certificate
>
> Configuring jitsi-meet-web-config
>
> The full path to the SSL key file on the server. If it has not been
> uploaded, now is a good time to do so.
> Full local server path to the SSL key file:
>
> /var/local/dehydrated/certs/jitsi.member.fsf.org/privkey.pem
>
> Configuring jitsi-meet-web-config
>
> The full path to the SSL certificate file on the server. If you
> haven't uploaded it, now is a good time to upload it in another
> console. Full local server path to the SSL certificate file:
>
> /var/local/dehydrated/certs/jitsi.member.fsf.org/fullchain.pem
>
> Configuring jitsi-meet-web-config
>
> You can easily add dial-in support to your meetings. To allow this we
> would need your permission to create a free JaaS (Jitsi as a Service)
> account for you.
> Add telephony to your Jitsi meetings?
> No
>
> After installing jitsi-meet then replace the upstream index.html
> file with the FSF customized one. Install a dpkg diversion so that
> package upgrades won't overwrite our customized file.
>
> /usr/share/jitsi-meet/index.html
>
> dpkg-divert --divert /usr/share/jitsi-meet/index.html.upstream
> --rename /usr/share/jitsi-meet/index.html
> cp /usr/share/jitsi-meet/index.html.upstream
> /usr/share/jitsi-meet/index.html
>
> root at jitsi4p:~# dpkg -l | grep -e prosody -e jitsi
> ii jitsi-meet 2.0.9111-1 all WebRTC
> JavaScript video conferences
> ii jitsi-meet-prosody 1.0.7658-1 all Prosody
> configuration for Jitsi Meet
> ii jitsi-meet-web 1.0.7658-1 all WebRTC
> JavaScript video conferences
> ii jitsi-meet-web-config 1.0.7658-1 all Configuration
> for web serving of Jitsi Meet
> ii jitsi-videobridge2 2.3-61-g814bffd6-1 all WebRTC
> compatible Selective Forwarding Unit (SFU)
> ii lua-basexx 0.4.1-jitsi1 all baseXX
> encoding/decoding library for Lua
> ii lua-cjson:amd64 2.1.0.10-jitsi1 amd64 JSON
> parser/encoder for Lua
> ii prosody 0.12.4-1~jammy1 amd64 Lightweight
> Jabber/XMPP server
>
> root at jitsi4p:~# dpkg -l | grep -e prosody -e jitsi | awk '{print$2}'
> jitsi-meet
> jitsi-meet-prosody
> jitsi-meet-web
> jitsi-meet-web-config
> jitsi-videobridge2
> lua-basexx
> lua-cjson:amd64
> prosody
>
> At that point things are usually working. Hopefully. If it is not
> working I have found it really impossible to debug. Everything uses
> encryption everywhere between the different parts of itself. If
> anything changes anywhere then usually the entire system is broken and
> it is easier to discard the VM and then start again. Hence the need
> to have most of the setup scripted and automated.
>
> Bob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nclug.org/pipermail/nclug/attachments/20240514/e2f59fb0/attachment-0001.htm>
More information about the NCLUG
mailing list