Describe the bug
In release 6.0.0 (via #1085) the account for running gunicorn was switched to an unprivileged user (see Dockerfile#L28).
The default value for PUPPETBOARD_PORT is 80 which is below 1024 which requires a privileged user to listen on:
[2024-12-02 11:12:27 +0100] [1] [INFO] Starting gunicorn 23.0.0
[2024-12-02 11:12:27 +0100] [1] [ERROR] connection to ('0.0.0.0', 80) failed: [Errno 13] Permission denied
[2024-12-02 11:12:28 +0100] [1] [ERROR] connection to ('0.0.0.0', 80) failed: [Errno 13] Permission denied
[2024-12-02 11:12:29 +0100] [1] [ERROR] connection to ('0.0.0.0', 80) failed: [Errno 13] Permission denied
[2024-12-02 11:12:30 +0100] [1] [ERROR] connection to ('0.0.0.0', 80) failed: [Errno 13] Permission denied
[2024-12-02 11:12:31 +0100] [1] [ERROR] connection to ('0.0.0.0', 80) failed: [Errno 13] Permission denied
[2024-12-02 11:12:32 +0100] [1] [ERROR] Can't connect to ('0.0.0.0', 80)
My expectation was that the default port would be changed to an unprivileged port alongside the user change. Unfortunately that's not the case, therefore the Puppetboard doesn't start in its delivered default configuration.
There is an easy workaround: Start the container with the PUPPETBOARD_PORT environment variable with a value above 1024.
It would definitely be good to also change the default value for PUPPETBOARD_PORT to a value above 1024. The user change itself was already a breaking change. IMHO changing the default value of the port is just in consequence and in line with that breaking change.
Puppetboard version
6.0.0
Environment and installation method
AWS Fargate running ghcr.io/voxpupuli/puppetboard:6.0.0@sha256:0bfdf8c95f68a0e6950055f09c44b4b04deb1aab2c4d765c00004616c4643503.
Describe the bug
In release 6.0.0 (via #1085) the account for running
gunicornwas switched to an unprivileged user (see Dockerfile#L28).The default value for
PUPPETBOARD_PORTis80which is below 1024 which requires a privileged user to listen on:My expectation was that the default port would be changed to an unprivileged port alongside the user change. Unfortunately that's not the case, therefore the Puppetboard doesn't start in its delivered default configuration.
There is an easy workaround: Start the container with the
PUPPETBOARD_PORTenvironment variable with a value above 1024.It would definitely be good to also change the default value for
PUPPETBOARD_PORTto a value above 1024. The user change itself was already a breaking change. IMHO changing the default value of the port is just in consequence and in line with that breaking change.Puppetboard version
6.0.0
Environment and installation method
AWS Fargate running
ghcr.io/voxpupuli/puppetboard:6.0.0@sha256:0bfdf8c95f68a0e6950055f09c44b4b04deb1aab2c4d765c00004616c4643503.