Regression: 502 with 0.20.4 (Docker & NPM) #2024
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#2024
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
I faced a regression when updating the frontend 0.20.3 -> 0.20.4. Now, Vikunja only gives a 502 Bad Gateway and the following lines are logged in the frontend container every 30s:
The deployment of the updated api container (0.20.2 -> 0.20.3) worked without problems.
The following setup works without problems with frontend/api versions 0.20.3/0.20.2 and 0.20.3/0.20.3 but not with 0.20.4/0.20.3:
NGINX Proxy Manager:
(shortened info, setup was done with only the NPM web-interface, i.e. no manual config editing)
Proxy Host
tasks.example.com
http://vikunja_frontend:80
Custom Locations
location /
http://vikunja_frontend:80
location ~* ^/(api|dav|.well-known)/
http://vikunja_api:3456
client_max_body_size 20M;
SSL
A valid SSL certificate for tasks.example.com is selected.
Only enabled option is
HTTP/2 Support
.Advanced
docker-compose.yml
Vikunja Frontend Version
0.20.3
Vikunja API Version
0.20.3
Browser and version
No response
Can you reproduce the bug on the Vikunja demo site?
No
Screenshots
No response
I was not able to reproduce this.
I've used this compose config, slightly adopted from yours:
And it seems to start up fine:
I don't have npm set up but the error you mentioned indicates a problem with the Vikunja frontend container, not npm.
Does this compose config work for you?
I can reproduce the issue.
The cause is, that the docker container now runs as user nginx. This user does most likely not exist on many host systems and is therefore unprivileged (I also think this is what was intended by the change).
Most distributions don't allow binding to ports below 1024 without root privileges. As vikunja defaults to 80 this is the case.
I see 3 solutions to this problem:
Here is the change for reference:
72a1aaa654/Dockerfile (L70)
I fixed it for myself by adding the following to the docker-compose file:
But the user account exists in the docker container?
I don't have a user called
nginx
or one with a user id of101
on my host system and I'm able to run the frontend container without issues.What OS are you using?
I dug a little and interestingly, the nginx process has the
cap_net_bind_service
linux capability. That means it should be able to run on ports < 1024 without being a root user.What Linux kernel are you running (with
uname -a
)? Which docker version? Which host OS and architecture?@konrad If I see it correctly the only change in your config is that the newest frontend version is set explicitly, isn't it? That still results in the same logged error messages.
grissi-r's fix regarding changing the ports actually works for me as well.
I'm using Ubuntu 22.04.2 LTS, Linux 5.4.0, x86_64, Docker version 23.0.1 and Docker compose version v2.16.0.
Yes that's correct. I just wanted to pin these versions.
I've tried something in
e7b89ae44f
. Can you pull the latest unstable docker image and check if that works for you? (On port 80 as original)EDIT: still building
EDIT 2: build is done, please try
Hi,
For my case, I used the latest release (well watchtower updated automatically to the latest front) and I had the same issue.
I added the following environment variables to my docker compose :
Now the frontend starts without having the permission denied problem. Yet it's stuck on "/docker-entrypoint.sh: Configuration complete; ready for start up"
@raedkit That sounds like it should work. Are you able to reach it?
Can you check if the unstable version works with port 80? (as per my comment above)
I will check with the unstable version and will let you know but I won't be able to test with port 80 as I'm on a Nas and this port is already used.
I meant without the
VIKUNJA_HTTP_PORT
env variable.I have the same problem with the unstable version. I will go back to 0.20.3 on the frontend until this problem is fixed.
@konrad If you need me to test anything please do not hesitate.
@raedkit New fix from
6cf2e574bf
is published and packaged as unstable, please try again.(still without the port config)
Thank you it's working as expected.
I retested now (without the port config) but with a different port than 80 (as explained above) and everything is OK :
That's awesome to hear. If there are no other finds, I'll publish a new version soon.
Btw, the
UMASK
,PUID
andGID
don't have an effect.Perfect (y).
I will stick to the unstable until this version is released. I sent you also a mail. Could you have a look at it ? Thanks in advance.
Should be fixed now.
Can confirm, unstable version
0.20.4+4-6cf2e574bf
with port80
works for me again.I've just released the fix - please update: https://vikunja.io/blog/2023/03/vikunja-frontend-v0.20.5-and-api-v0.20.4-was-released/
Going to close this issue now, thanks for everyone reporting and testing fixes.