Updating the role to 2019

[santiagomr]

Hi, thanks for sharing the role. In our organization we currently use Jitsi Meet. We set up our own instance based on your role, but modifications were necessary to make it functional to the current stable version of Jitsi Meet. We also fixed issues reported by users.

Here are the modifications, they include changes in:

• Debconf options
• Nginx configuration files
• Jitsi configuration files
• Use of personalized certificates
• Order of execution of tasks

[AmarOk1412]

@santiagomr I used your role to deploy a Jitsi instance. I only got one problem so far, jitsi-videobridge service doesn't start correctly due to https://community.jitsi.org/t/error-when-starting-jvb/16845

I had to remove $JVB_EXTRA_JVM_PARAMS from /etc/jitsi/videobridge/config

Also the final nginx start doesn't seems to work, I had to restart it manually :)

[santiagomr]

Thanks for your feedback @AmarOk1412. As you mentioned, the parameter $JVB_EXTRA_JVM_PARAMS was deprecated and is no longer part of the /etc/jitsi/videobridge/config file. Including this parameter in the file does not let the service start. To correct it, I updated the template.

Regarding the final nginx start that doesn't work (to which the services prosody, jicofo and jitsi-videobridge are added), it seems to be due to the handlers are skipping, although I still can't determine why this happens.

RUNNING HANDLER [jitsi_meet : restart nginx] ************************
skipping: [my-server.org]
RUNNING HANDLER [jitsi_meet : restart prosody] ************************
skipping: [my-server.org]
RUNNING HANDLER [jitsi_meet : restart jicofo] ************************
skipping: [my-server.org]
RUNNING HANDLER [jitsi_meet : restart jitsi-videobridge] ************************
skipping: [my-server.org]

do you have any idea?

[AmarOk1412]

Oh you did the fix even before I send a patch :D

For the nginx, I still don't know, I generally work on hosting things each Thursday. Last time I checked it seems that during the final nginx restart, the port 443 was used by something (but I didn't check further.

[santiagomr]

I will try then to check more in depth. Apparently we both have the same problem caused by different reasons.

[AmarOk1412]

Possibly, or just the same reason, I did a lot of things since the day I applied your roles. I probably just forgot the initial problem.

[AmarOk1412]

Ok. It is Thursday, I cleaned my VM and retried with the updated role.

This is the error for nginx:

~# systemctl status nginx.service 
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2019-05-23 18:53:08 EDT; 1min 32s ago
     Docs: man:nginx(8)
  Process: 19525 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=1/FAILURE)
  Process: 19522 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Main PID: 10285 (code=exited, status=0/SUCCESS)

May 23 18:53:05 garfield nginx[19525]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
May 23 18:53:06 garfield nginx[19525]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
May 23 18:53:06 garfield nginx[19525]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
May 23 18:53:07 garfield nginx[19525]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
May 23 18:53:07 garfield nginx[19525]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
May 23 18:53:08 garfield nginx[19525]: nginx: [emerg] still could not bind()
May 23 18:53:08 garfield systemd[1]: nginx.service: Control process exited, code=exited status=1
May 23 18:53:08 garfield systemd[1]: Failed to start A high performance web server and a reverse proxy server.
May 23 18:53:08 garfield systemd[1]: nginx.service: Unit entered failed state.
May 23 18:53:08 garfield systemd[1]: nginx.service: Failed with result 'exit-code'.

and indeed:

~# netstat -pluton | grep 443
tcp6       0      0 10.0.0.77:443           :::*                    LISTEN      15676/java           off (0.00/0/0)
tcp6       0      0 54.39.239.121:443       :::*                    LISTEN      15676/java           off (0.00/0/0)

The guilty process:

~# systemctl status jitsi-videobridge.service 
● jitsi-videobridge.service - Jitsi Videobridge
   Loaded: loaded (/lib/systemd/system/jitsi-videobridge.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-05-23 18:52:26 EDT; 5min ago
 Main PID: 15676 (java)

[AmarOk1412]

@santiagomr IMO, two solutions:

1. Change the handler to stop all services then restart.
2. Add a task to stop all services and then the handler will do its job. I think it's the best solution.

I did it on my instance and it works perfectly.

What do you think? Do you want a PR on your repo?

[santiagomr]

@AmarOk1412 the problem I'm having is actually that the handlers (as they are defined now) are skipped even though they have been triggered correctly.

I gladly accept your PR if you already have it resolved.

[AmarOk1412]

Sure. I will send you the PR this week