Jitsi-meet-turnserver Installation: DPKG Error due to Unreachable DNS Server

Hi,

first of all i want to thank you all for your work. In the current situation this helps many people.

TL;DR: The installation of jitsi-meet-turnserver seems to fail, when a DNS server (used for determining own public IP) is not accessible.

I am trying to install a Jitsi instance following the quick installation guide. For my case it is not sufficient to have only the UDP videobridge accessible. The server is inside a quite restrictive environment and at the moment only TCP Port 80 and 443 are allowed from outside the network. So I want to use a TURN-Server which is accessed via Nginx as reverse proxy on Port 443 and can use TURN and Jitsi Meet Web at the same time via Port 443.

I try to install using the following command (with no Nginx preinstalled):

$ sudo apt-get -y install jitsi-meet

The installation seems to run fine for all packages except jitsi-meet-turnserver. It fails with the following message:

Setting up jitsi-meet-turnserver (1.0.3969-1) ...
dpkg: error processing package jitsi-meet-turnserver (--configure):
 installed jitsi-meet-turnserver package post-installation script subprocess returned error exit status 9
Errors were encountered while processing:
 jitsi-meet-turnserver
E: Sub-process /usr/bin/dpkg returned an error code (1)

After this the installation itself seems to work, but without the TURN server and nginx is seems to be not configured for the TURN server.

Further debugging (thanks to Installation in Ubuntu 18.04) gives me the following output:

# debconf --frontend=readline bash -x /var/lib/dpkg/info/jitsi-meet-turnserver.postinst configure
+ set -e
+ case "$1" in
+ . /usr/share/debconf/confmodule
++ '[' '!' 1 ']'
++ '[' -z '' ']'
++ exec
++ '[' '' ']'
++ exec
++ DEBCONF_REDIR=1
++ export DEBCONF_REDIR
+ db_get jitsi-videobridge/jvb-hostname
+ _db_cmd 'GET jitsi-videobridge/jvb-hostname'
+ _db_internal_IFS='
'
+ IFS=' '
+ printf '%s\n' 'GET jitsi-videobridge/jvb-hostname'
+ IFS='
'
+ IFS='
'
+ read -r _db_internal_line
+ RET=meet.XXXXXX.de
+ case ${_db_internal_line%%[   ]*} in
+ return 0
+ '[' -z meet.XXXXXX.de ']'
+ JVB_HOSTNAME=meet.XXXXXX.de
+ TURN_CONFIG=/etc/turnserver.conf
+ NGINX_CONFIG=/etc/nginx/sites-available/meet.XXXXXX.de.conf
+ JITSI_MEET_CONFIG=/etc/jitsi/meet/meet.XXXXXX.de-config.js
+ NGINX_SITES_ENABLED=/etc/nginx/sites-enabled/
+ NGINX_CONFIG_ENABLED=/etc/nginx/sites-enabled/meet.XXXXXX.de.conf
+ for site in ${NGINX_SITES_ENABLED}*
+ '[' -f /etc/nginx/sites-enabled/default ']'
+ '[' /etc/nginx/sites-enabled/default '!=' /etc/nginx/sites-enabled/meet.XXXXXX.de.conf ']'
+ grep -q '^.*[[:space:]:]443[;[:space:]].*'
+ grep listen
+ grep -v '^[[:space:]]*#'
+ cat /etc/nginx/sites-enabled/default
+ for site in ${NGINX_SITES_ENABLED}*
+ '[' -f /etc/nginx/sites-enabled/meet.XXXXXX.de.conf ']'
+ '[' /etc/nginx/sites-enabled/meet.XXXXXX.de.conf '!=' /etc/nginx/sites-enabled/meet.XXXXXX.de.conf ']'
+ continue
+ [[ -f /etc/turnserver.conf ]]
+ db_get jitsi-meet-turnserver/jvb-hostname
+ _db_cmd 'GET jitsi-meet-turnserver/jvb-hostname'
+ _db_internal_IFS='
'
+ IFS=' '
+ printf '%s\n' 'GET jitsi-meet-turnserver/jvb-hostname'
+ IFS='
'
+ IFS='
'
+ read -r _db_internal_line
+ RET=meet.XXXXXX.de
+ case ${_db_internal_line%%[   ]*} in
+ return 0
+ JVB_HOSTNAME_OLD=meet.XXXXXX.de
+ '[' -n meet.XXXXXX.de ']'
+ '[' '!' meet.XXXXXX.de = meet.XXXXXX.de ']'
+ db_get jitsi-meet/jvb-serve
+ _db_cmd 'GET jitsi-meet/jvb-serve'
+ _db_internal_IFS='
'
+ IFS=' '
+ printf '%s\n' 'GET jitsi-meet/jvb-serve'
+ IFS='
'
+ IFS='
'
+ read -r _db_internal_line
+ RET='10 jitsi-meet/jvb-serve doesn'\''t exist'
+ case ${_db_internal_line%%[   ]*} in
+ return 10
+ true
+ '[' '!' -f /etc/nginx/sites-available/meet.XXXXXX.de.conf -o '10 jitsi-meet/jvb-serve doesn'\''t exist' = true ']'
+ [[ -f /etc/turnserver.conf ]]
+ db_set jitsi-meet-turnserver/jvb-hostname meet.XXXXXX.de
+ _db_cmd 'SET jitsi-meet-turnserver/jvb-hostname' meet.XXXXXX.de
+ _db_internal_IFS='
'
+ IFS=' '
+ printf '%s\n' 'SET jitsi-meet-turnserver/jvb-hostname meet.XXXXXX.de'
+ IFS='
'
+ IFS='
'
+ read -r _db_internal_line
+ RET='value set'
+ case ${_db_internal_line%%[   ]*} in
+ return 0
+ db_get jitsi-meet-prosody/turn-secret
+ _db_cmd 'GET jitsi-meet-prosody/turn-secret'
+ _db_internal_IFS='
'
+ IFS=' '
+ printf '%s\n' 'GET jitsi-meet-prosody/turn-secret'
+ IFS='
'
+ IFS='
'
+ read -r _db_internal_line
+ RET=s7fmc3Bv
+ case ${_db_internal_line%%[   ]*} in
+ return 0
+ '[' -z s7fmc3Bv ']'
+ TURN_SECRET=s7fmc3Bv
++ dig +short myip.opendns.com @resolver1.opendns.com
+ PUBLIC_IP=';; connection timed out; no servers could be reached'

It seems that the installation fails at the point where the DNS request is made. Is there a way to set this IP manually, without the DNS request that “reflects” the own IP? Is there any workaround?

I can understand that it is a convenient method to do so, but in some cases this might not be good:

  • Restrictive firewalls which do not allow DNS access to the DNS server resolver1.opendns.com. (In my case the firewalls restrict DNS to the oranizations trusted own DNS servers.)
  • Those DNS requests are small information leaks, as it reveals the servers IP adress. This might be paranoid, but for intern-only installations with no access from the internet this might be unwanted. However, this behavior is also unexpected.

Thanks for bringing this up, we can think of something … so stay tuned.

1 Like

Fix it !
it’s open source :slight_smile: I’m sure that they will welcome your PR. I’d say that changing the script to check that the public_ip variable is set and if not ask it in the debian usual way could be accepted.
Me, I am lazy person and I have opened a hole for this site in my firewall :slight_smile:
Or if you don’t want to contribute, download the deb, extract it, patch the postinst script, pack it again and install it manually.

1 Like

I already thought about it. Maybe I can get it done later! :wink: I’m a little hesitant because I have no experience with building DEBs. And wanted to check if anyone has a quick solution…

I have not the complete solution, but here are the incantations to download the deb and extract it:
apt download jitsi-meet-turnserver
dpkg --extract jitsi-meet-turnserver_1.0.3969-1_all.deb jitsi-turnserver
editing the file to setup your public IP is real easy.
Now, I have never done the re-packing from source so I don’t have the correct incantion in my files. I am sure that it can be done but I may be wrong :slight_smile:

I did this change, which at least will not fail install and will print a warning to the user to set it manually: https://github.com/jitsi/jitsi-meet/pull/5729/commits/02798ad1ccb5b5b1de7fbb698bd7cb11c4927bb8

1 Like

That should do the trick I think. Thank you, you are very fast! :+1:

As I thought about fixing it myself, I had a quick look at the source code. Maybe I don’t get it right, but I don’t see where $PUBLIC_IP is used in jitsi-meet-turnserver.postinst. Is it even required?

(Sorry, I should have started this discussion on GitHub maybe…)

are you sure ? I’d try to add a set +e before the dig and redo set -e after.

@klmmr Hey you are so right! So seems coturn can work with dns there … So more testing to be done.
Can you test is this the case for you?

1 Like

@damencho I will try later and give you feedback.

to think of it,you may try to actually remove the line and run the postinst file again. It’s a post install command after all, that is, the software is actually installed.

1 Like

@damencho I tested it on my server by commenting out PUBLIC_IP=$(dig +short myip.opendns.com @resolver1.opendns.com) in line 109 of /var/lib/dpkg/info/jitsi-meet-turnserver.postinst, as this file was cached (from the uncomplete installation) and I didn’t had to pack/unpack and modify the deb.

The I ran sudo apt install jitsi-meet-turnserver. It seems to work, but I get the following warning:

W: APT had planned for dpkg to do more than it reported back (0 vs 4).
  Affected packages: jitsi-meet-turnserver:amd64

The TURN-Server and nginx seems to be running fine after a reboot. However, the setup as a whole does not work. When one of the participants (extern) should use the TURN server and some participants are connected via internal network, there is no video/audio to and from the external participant.

But this might be a different problem. I will have a closer look tomorrow.