Unmet dependencies in Install Jitsi Meet

[robrant]

Hi,

Would really like to use this playbook, but I had the following problem:

13:57 ansible-jitsi$> ansible-playbook -i hosts playbook.yml 

PLAY [Configure jitsi-meet server.] ********************************************

TASK [setup] *******************************************************************
ok: [jitsi]

TASK [freedomofpress.jitsi-meet : Install base apt packages.] ******************
ok: [jitsi] => (item=[u'apt-transport-https', u'default-jre-headless'])

TASK [freedomofpress.jitsi-meet : Remove deprecated repo filename.] ************
ok: [jitsi]

TASK [freedomofpress.jitsi-meet : Determine repo strategy.] ********************
ok: [jitsi]

TASK [freedomofpress.jitsi-meet : Configure signing key for Jitsi repository.] *
ok: [jitsi]

TASK [freedomofpress.jitsi-meet : Install Jitsi apt repo.] *********************
changed: [jitsi] => (item={'key': u'unstable', 'value': {u'repo_url': u'deb https://download.jitsi.org unstable/'}})
ok: [jitsi] => (item={'key': u'stable', 'value': {u'repo_url': u'deb https://download.jitsi.org/ stable/'}})

TASK [freedomofpress.jitsi-meet : Install Jitsi Meet] **************************
fatal: [jitsi]: FAILED! => {"cache_update_time": 1495630648, "cache_updated": false, "changed": false, "failed": true, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"     install 'jitsi-meet'' failed: E: Unable to correct problems, you have held broken packages.\n", "stderr": "E: Unable to correct problems, you have held broken packages.\n", "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSome packages could not be installed. This may mean that you have\nrequested an impossible situation or if you are using the unstable\ndistribution that some required packages have not yet been created\nor been moved out of Incoming.\nThe following information may help to resolve the situation:\n\nThe following packages have unmet dependencies:\n jitsi-meet : Depends: jitsi-meet-web-config (= 1.0.1967-1) but it is not going to be installed\n", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information...", "Some packages could not be installed. This may mean that you have", "requested an impossible situation or if you are using the unstable", "distribution that some required packages have not yet been created", "or been moved out of Incoming.", "The following information may help to resolve the situation:", "", "The following packages have unmet dependencies:", " jitsi-meet : Depends: jitsi-meet-web-config (= 1.0.1967-1) but it is not going to be installed"]}
    to retry, use: --limit @/Users/me/Projects/Jitsi/ansible-jitsi/playbook.retry

Can you help?

Thanks very much

[robrant]

Progress. I added:

- name: Run the equivalent of "apt-get update" as a separate step
  apt:
    upgrade: dist

and

- name: Install Jitsi Meet Web Config
  apt:
    name: jitsi-meet-web-config
    state: latest
    update_cache: yes
    cache_valid_time: 3600

I'm not sure the first actually solved anything, but the second definitely made a difference, which makes sense given it was looking for jitsi-meet-web-config.

Is this a peculiarity with the way I am doing it or is it worth me making a pull request?

[conorsch]

What platform are you running? The warning about unstable repos has me wondering. (Use lsb_release -a and paste the output here.) The role is most heavily tested on Debian Jessie, but should work well on recent Ubuntus.

In general you should use a separate strategy for keeping your apt packages up to date, such as a dedicated role. Using state=latest is with the apt module considered bad practice, so the role won't automatically update anything—use unattended-upgrades or similar to keep the packages up to date after initial install.

The jitsi-meet-web-config package is a dependency of jitsi-meet, so it'll get installed automatically. When creating a new host, I recommend you make sure the packages are up to date right out of the gate:

- name: Run the equivalent of "apt-get update" as a separate step
  apt:
    upgrade: dist
    update_cache: yes
    cache_valid_time: 3600

Then proceed with applying roles.

[robrant]

You're right about doing my own admin (update, etc.) before running this role - i thought of that just after i posted the fix; thanks though.

I am running Jessie, on AWS:

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.8 (jessie)
Release:    8.8
Codename:   jessie

I think I also observed 2 other issues:

1. server_names_hash_bucket_size - this was in another file (not localhost, which gets removed, but one called something like ok.conf). The duplication made nginx unhappy.

2. A weirder behaviour whereby jitsi wouldn't work (no video displayed, etc.) until after the box was rebooted.

I'm going to blat the box and start again, so I'll give you more details if I can repeat it. I appreciate there might be some quirks with the aws box I'm using?

[conorsch]

I am running Jessie, on AWS

Should work OK. The apt problems you saw were likely related to stale cache lists and non-jitsi packages requiring updates.

server_names_hash_bucket_size - this was in another file

Hm, that may be a consequence of the jitsi-meet maintainers moving config items around. In production, we set jitsi_meet_configure_nginx: false, and use jdauphant.nginx to handle the nginx configuration aspect. The role defaults may have drifted from what's appropriate with the current stable packages for jitsi-meet.

Be advised that the ansible_fqdn var is what determines the nginx hostname files if you're using HTTPS, so make sure to name your host with that in mind, or simply override it at the playbook/site level.

A weirder behaviour whereby jitsi wouldn't work (no video displayed, etc.) until after the box was rebooted.

To debug that, try bouncing the services:

• sudo systemctl restart prosody
• sudo systemctl restart jicofo
• sudo systemctl restart jitsi-videobridge
• sudo systemctl restart nginx

And test the web client between each bounce. If still unresolved, check that the services are indeed listening on the expected ports with sudo netstat -lntp.

I'm going to blat the box and start again, so I'll give you more details if I can repeat it. I appreciate there might be some quirks with the aws box I'm using?

Precisely. Please do share any feedback you get from testing on AWS. Right now I suspect config drift for the default vars than something AWS-specific.

[robrant]

Just to report back on part of the puzzle: nginx still fails to start oob. Here's the play readout:

RUNNING HANDLER [freedomofpress.jitsi-meet : restart nginx] ********************
fatal: [jitsi]: FAILED! => {"changed": false, "failed": true, "msg": "Unable to restart service nginx: Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details.\n"}

And here's part of journalctl -xe:

May 24 20:36:12 ip- nginx[31503]: nginx: [emerg] "server_names_hash_bucket_size" directive is duplicate in /etc/nginx/sites-enabled/ok.conf:1
May 24 20:36:12 ip- nginx[31503]: nginx: configuration file /etc/nginx/nginx.conf test failed
May 24 20:36:12 ip- systemd[1]: nginx.service: control process exited, code=exited status=1
May 24 20:36:12 ip- systemd[1]: Failed to start A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit nginx.service has failed.
-- 
-- The result is failed.

Note the ok.conf ^, which looks like this:

server_names_hash_bucket_size 64

server {
    listen 80;
    server_name ok;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
    server_name ok;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "<redacted>";

    add_header Strict-Transport-Security "max-age=31536000";

    ssl_certificate /etc/jitsi/meet/ok.crt;
    ssl_certificate_key /etc/jitsi/meet/ok.key;

    root /usr/share/jitsi-meet;
    index index.html index.htm;
    error_page 404 /static/404.html;

    location /config.js {
        alias /etc/jitsi/meet/ok-config.js;
    }

    location ~ ^/([a-zA-Z0-9=\?]+)$ {
        rewrite ^/(.*)$ / break;
    }

    location / {
        ssi on;
    }

    # Backward compatibility
    location ~ /external_api.* {
        root /usr/share/jitsi-meet/libs;
    }

    # BOSH
    location /http-bind {
        proxy_pass      http://localhost:5280/http-bind;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;
    }
}

It's a simple manual fix (comment the server_names_hash_bucket_size from this ok.conf file), but i thought i'd flag it in case others have the same problem. I realised some of this might come from using the unstable repo, which feels like a bit of an error while I'm just trying to get something up and running.

On the weird video display, I ran the systemctl restarts, but forgot to check the UI between. It came up as a result of one of them being restarted though. I'll re-do and find the culprit.

Having got to the point of having working video, I couldn't have 2 videos at anyone time. Someone joining the meet would boot the other person off. Probably more of a jitsi-meet issue than for this repo, but i thought i'd mention it in case you know an easy fix/debug.

Thanks!

[conorsch]

Are you overriding any of the default vars? The ok string you reference is how the jitsi_meet_server_name var resolves—so you can override that as needed to get the value you want, since ansible_fqdn does not seem to be a true FQDN in your case.

[robrant]

Yeah, my play looks like this so I'm pretty sure i'm overriding the right var:

- name: Configure jitsi-meet server.
  hosts: jitsi
  vars:
    # Change this to match the DNS entry for your host IP.
    jitsi_meet_server_name: jitsi.mydomain.net
    jitsi_meet_use_nightly_apt_repo: false
  roles:
    - role: freedomofpress.jitsi-meet
      jitsi_meet_ssl_cert_path: "/etc/ssl/certs/ourjitsi.mydomain.net.crt"
      jitsi_meet_ssl_key_path: "/etc/ssl/private/ourjitsi.mydomain.net.key"
      become: yes
      tags: jitsi

In the hosts file, i'm setting ansible_fqdn (but i wasn't previously).

I still get an ok.conf file with server_names_hash_bucket_size in it. Once that's commented and I've restarted all 4 services I can connect and get video of myself.

It's not quite there though: when anyone else tries to connect, it kicks us both off. Both browsers then try to reconnect. The first one that gets there, reconnects, but when the second one reconnects, it kicks us both out again. And so on...

This is the only issue i can find in the logs:

Jicofo 2017-05-25 12:20:30.790 SEVERE: [15] org.jitsi.jicofo.JvbDoctor.log() Unexpected error returned by the bridge: jitsi-videobridge.jitsi.mydomain.net, err: <iq id="RFm8j-369" to="focus@auth.jitsi.mydomain.net/focus1146475286578" from="jitsi-videobridge.jitsi.mydomain.net" type="error"><healthcheck xmlns='http://jitsi.org/protocol/healthcheck' /><error code="401" type="AUTH"><not-authorized xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>

Any pointers or useful tips on debugging? I appreciate the issue might be a jitsi-meet one rather than anything to do with this playbook, but i thought i'd ask.

[conorsch]

@robrant Test the changes described in #37—if you manually copy the content to the new file location in /etc/, you should be able to have multi-party videochats. Please confirm if that works for you, and I'll open a PR if so.