Cryptpad:NGINX NGINX Configuration Invalid
manlycucumber opened this issue · 5 comments
The latest update generates an invalid nginx configuration.
Docker Image: promasu/cryptpad:nginx
Log:
nginx: [warn] low address bits of 172.20.0.0/8 are meaningless in /etc/nginx/conf.d/cryptpad.conf:11
nginx: [warn] low address bits of 172.20.0.0/8 are meaningless in /etc/nginx/conf.d/cryptpad.conf:17
nginx: [emerg] "real_ip_recursive" directive is duplicate in /etc/nginx/conf.d/cryptpad.conf:18
Removing the duplicate "real_ip_recursive" directive then causes this error:
nginx: [warn] low address bits of 172.20.0.0/8 are meaningless in /etc/nginx/conf.d/cryptpad.conf:11
nginx: [emerg] open() "/etc/nginx/letsencrypt-webroot" failed (2: No such file or directory) in /etc/nginx/conf.d/cryptpad.conf:17
Then removing the webroot line leaves this error:
nginx: [warn] low address bits of 172.20.0.0/8 are meaningless in /etc/nginx/conf.d/cryptpad.conf:11
nginx: [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in /etc/nginx/conf.d/cryptpad.conf:7
I think the changes made in this commit cryptpad/cryptpad@1b731e2 are causing the issue.
Attaching a console to my docker container and removing the following lines (14-22) from /etc/nginx/conf.d/cryptpad.conf was able to get me back up and running:
listen [::]:443 ssl;
# Set trusted proxy and header containing real client IP
set_real_ip_from 172.20.0.0/8;
real_ip_recursive on;
real_ip_header X-Forwarded-For;
# Let's Encrypt webroot
include letsencrypt-webroot;
I can confirm this is a breakind change and "latest" is now broken
Hello, same problem here !
How did you have fixed the problem ? How do you use the Nginx image ?
Thank you.
Hey @luluwebmaster,
You'll need to attach a console to your Docker container, navigate to /etc/nginx/conf.d/ and modify cryptpad.conf by removing the following lines:
listen [::]:443 ssl;
Set trusted proxy and header containing real client IP
set_real_ip_from 172.20.0.0/8;
real_ip_recursive on;
real_ip_header X-Forwarded-For;
Let's Encrypt webroot
include letsencrypt-webroot;
If you need more detailed instructions, you can DM on discord @manlycucumber#0796 and I can walk you through it.
Cheers!
Nice, thank you for the help.
My instance work correctly now !
Edit : Waiting for a clean fix now.
As this is ultimately caused by the initalisation script https://github.com/xwiki-labs/cryptpad-docker/blob/main/docker-entrypoint.sh, we could do good to organise here around what needs to be changed.
It is using https://github.com/xwiki-labs/cryptpad/blob/main/docs/example.nginx.conf and adapting it to our needs here.
This is what the first 22 lines of the generated cryptpad.conf
look like in such a case:
`head -n 22 cryptpad.conf`
# This file is included strictly as an example of how Nginx can be configured
# to work with CryptPad. This example WILL NOT WORK AS IS. For best results,
# compare the sections of this configuration file against a working CryptPad
# installation (http server by the Nodejs process). If you are using CryptPad
# in production and require professional support please contact sales@cryptpad.fr
server {
listen 80;
# Set trusted proxy and header containing real client IP
set_real_ip_from 172.19.0.0/8;
real_ip_recursive on;
real_ip_header X-Forwarded-For;
listen [::]:443 ssl;
# Set trusted proxy and header containing real client IP
set_real_ip_from 172.19.0.0/8;
real_ip_recursive on;
real_ip_header X-Forwarded-For;
# Let's Encrypt webroot
include letsencrypt-webroot;
It visualises very well how the current script in conjunction with the new example configuration creates the doubled entries.
To alleviate the issue with the configuration state being reapplied every time the container restarts, we can provide our own configuration file, and opt out from generation with that:
docker cp comexamplecryptpad_cryptpad_1:/etc/nginx/conf.d/cryptpad.conf . # Copying the configuration state from the container
sed -i -e '14,22d' cryptpad.conf # Delete the unnecessary lines
sed -i '/^ volumes:$/a \ \ \ \ \ \ - ./cryptpad.conf:/etc/nginx/conf.d/cryptpad.conf' docker-compose.yml
docker-compose restart
In the aftermath, we may also try to understand why the entrypoint generates such havoc and doubles those entries:
From looking at the Blame view on the example configuration, it was caused by introducing a second listen
directive for self-serving HTTPS
https://github.com/xwiki-labs/cryptpad/blame/main/docs/example.nginx.conf
in the commit
This
is applied on each listen directive
(G
) and thus twice, why we also see the doubling of modifications.