Docker-jitsi-meet: nginx.conf quick start procedure fail

[Franselbaer]

If you follow the quick start quide you'll run into an error on web container...

/config/nginx.conf file not found

You need to add

mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb}
touch ~/.jitsi-meet-cfg/web/nginx.conf

to your quickstart guide for a quick fix.

[saghul]

That shouldn't be needed. What exact steps did you follow and werre you using Docker or something else?

[Franselbaer]

Just started with quickstart and git pull today on Ubunti 16.04

Saúl Ibarra Corretgé [e-mail] schrieb am Do., 2. Apr.
2020, 11:53:

That shouldn't be needed. What exact steps did you follow and werre you
using Docker or something else?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jitsi/docker-jitsi-meet/issues/365#issuecomment-607743035,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACUIOEJVRYOZLZ6NPRR3GO3RKROCNANCNFSM4L2GR4WA
.

[andre-stefanov]

can confirm same issue

[saghul]

Can you paste the logs of the web container?

[andre-stefanov]

web_1      | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
web_1      | [s6-init] ensuring user provided files have correct perms...exited 0.
web_1      | [fix-attrs.d] applying ownership & permissions fixes...
web_1      | [fix-attrs.d] done.
web_1      | [cont-init.d] executing container initialization scripts...
web_1      | [cont-init.d] 01-set-timezone: executing...
web_1      | [cont-init.d] 01-set-timezone: exited 0.
web_1      | [cont-init.d] 10-config: executing...
web_1      | Saving debug log to /var/log/letsencrypt/letsencrypt.log
web_1      | Plugins selected: Authenticator standalone, Installer None
web_1      | Obtaining a new certificate
web_1      | Performing the following challenges:
web_1      | http-01 challenge for ###REPLACED_DOMAIN###
web_1      | Waiting for verification...
web_1      | Cleaning up challenges
web_1      | IMPORTANT NOTES:
web_1      |  - The following errors were reported by the server:
web_1      |
web_1      |    Domain: ###REPLACED_DOMAIN###
web_1      |    Type:   connection
web_1      |    Detail: Fetching
web_1      |    http://###REPLACED_DOMAIN###/.well-known/acme-challenge/##TOKEN##:
web_1      |    Connection refused
web_1      |
web_1      |    To fix these errors, please make sure that your domain name was
web_1      |    entered correctly and the DNS A/AAAA record(s) for that domain
web_1      |    contain(s) the right IP address. Additionally, please check that
web_1      |    your computer has a publicly routable IP address and that no
web_1      |    firewalls are preventing the server from communicating with the
web_1      |    client. If you're using the webroot plugin, you should also verify
web_1      |    that you are serving files from the webroot path you provided.
web_1      |  - Your account credentials have been saved in your Certbot
web_1      |    configuration directory at /etc/letsencrypt. You should make a
web_1      |    secure backup of this folder now. This configuration directory will
web_1      |    also contain certificates and private keys obtained by Certbot so
web_1      |    making regular backups of this folder is ideal.
web_1      | Failed authorization procedure. ###REPLACED_DOMAIN### (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://###REPLACED_DOMAIN###/.well-known/acme-challenge/Ty2HWUNhpKbIC9nU672Oe9L0h2UGYvaBRcm3GNROOw4: Connection refused
web_1      | Failed to obtain a certificate from the Let's Encrypt CA.
web_1      | Exiting.
web_1      | [cont-init.d] 10-config: exited 1.
web_1      | [cont-init.d] done.
web_1      | [services.d] starting services
web_1      | [services.d] done.
web_1      | nginx: [emerg] open() "/config/nginx/nginx.conf" failed (2: No such file or directory)
web_1      | nginx: [emerg] open() "/config/nginx/nginx.conf" failed (2: No such file or directory)
web_1      | nginx: [emerg] open() "/config/nginx/nginx.conf" failed (2: No such file or directory)
web_1      | nginx: [emerg] open() "/config/nginx/nginx.conf" failed (2: No such file or directory)

Maybe it is related to #315

[laenan8466]

I can confirm this Issue as well. But for me the solution recommended from @Franselbaer doesn't work.

You need to add

mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb}
touch ~/.jitsi-meet-cfg/web/nginx.conf

to your quickstart guide for a quick fix.

EDIT: Solved for now by using external reverse Proxy.

[andre-stefanov]

complettely reinstalling my OS and configuring jitsi docker-compose anew helped ... now everything is working fine. Using current master

[sssanjaya]

getting same error tried everything no luck
nginx: [emerg] open() "/config/nginx/nginx.conf" failed (2: No such file or directory)

anyone found out solution for this?

[The-Ludwig]

i also have the exact same issue

[sssanjaya]

Can anyone suggest any solutions for now?

[dahawk]

I didn't have the time to look into the cause of this problem so far. As a quickfix you can take the content of https://github.com/jitsi/docker-jitsi-meet/blob/master/web/rootfs/defaults/nginx.conf and place them in them under ~/.jitsi-meet-cfg/web/nginx/nginx.conf

This file does not contain any templating or variables that are substituted during build or startup so taking this file should not cause problems and works for me so far.

My guess is that ...web/rootfs/defaults/nginx.conf should be copied to container's config dir but is left out for some reason.

[JaredRymer]

I had the same issue. But the workaround that dahawk posted worked. I thought it was working previous without any prior changes. But I really don't have a way to prove that. Oh well.

[dahawk]

I had some time to look around. The error message only appears when let's encrypt is used.
As I have set up my jitsi instance with the workaround mentioned above, I don't have any log messages for what happens if the file is not present after a lets encrypt certificate was issued.

Unfortunately I don't have any available domains on which I can test the lets encrypt execution and the corresponding log messages. Certbot failing will break the s6 script execution before the nginx config files are copied.

[laenan8466]

Thank's @dahawk. Should the config/web/nginx folder exist after a first run? Mine doesn't. Adding folder and file didn't solved the problem for me.

[dahawk]

In order:
@laenan8466 I see a ~/.jitsi-meet-cfg/web/nginx (which is mapped to /config/web/nginx in the container) after the first run, with and without the letsencrypt error.

Secondly
I think I found the root cause for the problem.
My current theory is that, if you keep the original value of 8000 from the env.example file, docker will be told to map the container port 80 to the host port 8000. (Assume port 8000 for the following description).
certbot --standalone will start a webserver on port 80 in the container for the verification. This will be mapped to port 8000 on the host. Letsencrypt verification will attempt to contact the standalone server on port 80 (default behaviour if it's not overridden) which is not present on the host (but 8000 is instead).
As written above, if the letsencrypt step fails, the nginx configs will not be copied to their destination but s6 will try to start nginx which then fails with the message

nginx: [emerg] open() "/config/nginx/nginx.conf" failed (2: No such file or directory)

Seeing it from another angle, if you change the HTTP_PORT variable to 80, letsencrypt is able to access the standalone verification.

My suggestion for a fix would be to add --http-01-port HTTP01_PORT to the certbot call, so that certbot will use the same port as specified in the .env file.
I am currently unable to produce a working jitsi/web image locally with which I could verify my changes. If I add the --http-01-port flag to the script and pass $HTTP_PORT as value, I get an error message that indicates, that the variable $HTTP_PORT is not populated when web/rootfs/etc/cont-init.d/10-script is executed.
I am not familiar with s6 so I'm not sure if I find a solution any time soon -> unfortunately no pull request from me.

[EDIT]
rewrote the text and forgot to move the error message to the correct location.

[dahawk]

Occupational Hazard of a software developer: Having a brain wave when going to bed.

$HTTP_PORT was empty, because docker-compose.yml did not list it as ENV for the web service.
I tried to fix this but discovered a misunderstanding on my part of --http-01-port. This is meant for port forwarding/NAT situations, not for changing the public port that is used for http verification.
The letsencrypt docs specify, that http-01 only works when the standalone server of certbot is internet accessible on port 80 or 443 (a port mapping of 8000:80 or 8443:443 as shown in the env.example will not work).

If I made a mistake in my analysis or misunderstood something, please let me know.

[cooperka]

For others finding this, I am using Cloudflare configured with SSL/TLS encryption mode Full (may be related). I was seeing a similar error:

Failed authorization procedure. my-example.com (http-01): urn:ietf:params:acme:error:unauthorized
:: The client lacks sufficient authorization
:: Invalid response from https://my-example.com/.well-known/acme-challenge/foo

leading to nginx: [emerg] open() "/config/nginx/nginx.conf" failed

In my case I simply set ENABLE_LETSENCRYPT=0 and let Cloudflare handle my HTTPS automatically. Everything is now working successfully.

[sssanjaya]

I didn't have the time to look into the cause of this problem so far. As a quickfix you can take the content of https://github.com/jitsi/docker-jitsi-meet/blob/master/web/rootfs/defaults/nginx.conf and place them in them under ~/.jitsi-meet-cfg/web/nginx/nginx.conf

This file does not contain any templating or variables that are substituted during build or startup so taking this file should not cause problems and works for me so far.

My guess is that ...web/rootfs/defaults/nginx.conf should be copied to container's config dir but is left out for some reason.

yes i confirm this is solution for now. Worked like a charm, thank you so much.

[JaredRymer]

Upon further review of the output from docker-compose, I notice that Let's Encrypt was complaining that I had exceeded the maximum amount of cert registrations in a week. This was because I was removing the .jitsi-meet-cfg folder. I could have saved my valid keys if I had moved the folders instead. Maybe the documentation should reflect a warning? I can do a pull request if that would be accepted.

I don't know if this a red herring, to be honest.

[saghul]

The problem is that we were not failing to start the container if the init scripty failed (whatever the reason was). That is fixed, so if certbot fails, for example, the container won't start.

@JaredRymer agreed about the keys, a PR would be welcome!