New Container start
** Supporting Details** Provide the following:
- Headscale Version: ghcr.io/gurucomputing/headscale-ui:2024.02.24-beta1
Describe the bug
no Caddyfile detected, copying across default config
Starting Caddy
{"level":"info","ts":1709236469.6964498,"msg":"using provided configuration","config_file":"/data/Caddyfile","config_adapter":"caddyfile"}
{"level":"info","ts":1709236469.701366,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"o
rigins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
{"level":"info","ts":1709236469.7019582,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000
595d80"}
{"level":"info","ts":1709236469.7063584,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connect
ion policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"warn","ts":1709236469.7063966,"logger":"http.auto_https","msg":"automatic HTTP->HTTPS redirects are disabled","server_name":"srv0
"}
{"level":"warn","ts":1709236469.7064192,"logger":"http.auto_https","msg":"server is listening only on the HTTP port, so no automatic HTTPS
will be applied to this server","server_name":"srv1","http_port":80}
{"level":"info","ts":1709236469.70717,"logger":"tls.cache.maintenance","msg":"stopped background certificate maintenance","cache":"0xc00059
5d80"}
Error: loading initial config: loading new config: http app module: start: listening on :443: listen tcp :443: bind: permission denied
Problems:
- it miss the Caddyfile (on correct path)
- port like 443 is not allowed for non-root user
I can't recreate the problem, the production container appears fully functional (see logs example below). If you're using a custom caddyfile, make sure you got the capitalisation correct. Also make sure there aren't any additional host security protections preventing containers from binding on privileged ports. If there are, you can use the environment variables to bind to unprivileged ports instead.
no Caddyfile detected, copying across default config
Starting Caddy
{"level":"info","ts":1709251751.6514857,"msg":"using provided configuration","config_file":"/data/Caddyfile","config_adapter":"caddyfile"}
{"level":"info","ts":1709251751.6546135,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
{"level":"info","ts":1709251751.6550517,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0005aae00"}
{"level":"warn","ts":1709251751.6584222,"logger":"http.auto_https","msg":"server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server","server_name":"srv1","http_port":80}
{"level":"info","ts":1709251751.6584508,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"warn","ts":1709251751.6584604,"logger":"http.auto_https","msg":"automatic HTTP->HTTPS redirects are disabled","server_name":"srv0"}
{"level":"info","ts":1709251751.6591365,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1709251751.6594176,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."}
{"level":"info","ts":1709251751.6597316,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"info","ts":1709251751.6598797,"logger":"http.log","msg":"server running","name":"srv1","protocols":["h1","h2","h3"]}
{"level":"info","ts":1709251751.6599333,"logger":"pki.ca.local","msg":"root certificate trust store installation disabled; unconfigured clients may show warnings","path":"storage:pki/authorities/local/root.crt"}
{"level":"warn","ts":1709251751.6600153,"logger":"tls","msg":"YOUR SERVER MAY BE VULNERABLE TO ABUSE: on-demand TLS is enabled, but no protections are in place","docs":"https://caddyserver.com/docs/automatic-https#on-demand-tls"}
{"level":"info","ts":1709251751.6604106,"msg":"autosaved config (load with --resume flag)","file":"/home/appuser/.config/caddy/autosave.json"}
{"level":"info","ts":1709251751.6604326,"msg":"serving initial configuration"}
{"level":"info","ts":1709251751.667576,"logger":"tls","msg":"cleaning storage unit","storage":"FileStorage:/home/appuser/.local/share/caddy"}
{"level":"info","ts":1709251751.667848,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1709251780.7150126,"logger":"tls.on_demand","msg":"obtaining new certificate","remote_ip":"172.21.0.4","remote_port":"46396","server_name":"dev-hs-ui"}
{"level":"info","ts":1709251780.7156596,"logger":"tls.obtain","msg":"acquiring lock","identifier":"dev-hs-ui"}
{"level":"info","ts":1709251780.7237587,"logger":"tls.obtain","msg":"lock acquired","identifier":"dev-hs-ui"}
{"level":"info","ts":1709251780.7238925,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"dev-hs-ui"}
{"level":"info","ts":1709251780.726499,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"dev-hs-ui"}
{"level":"info","ts":1709251780.7266126,"logger":"tls.obtain","msg":"releasing lock","identifier":"dev-hs-ui"}
{"level":"warn","ts":1709251780.7273214,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [dev-hs-ui]: no OCSP server specified in certificate","identifiers":["dev-hs-ui"]}
I do bot use any Caddyfile (i miss underatand your log after takr just a second look, that you copy one in).
What you mean with security protection makes no sense for me. inside of container and host are different and you create an appuser inside of your container and start with it caddy ...
i try to replace the current running 2023.01.30-beta-1 and rollback now.
But yes the env is a good hintc
I do bot use any Caddyfile (i miss underatand your log after takr just a second look, that you copy one in).
What you mean with security protection makes no sense for me. inside of container and host are different and you create an
appuserinside of your container and start with it caddy ...i try to replace the current running
2023.01.30-beta-1and rollback now.But yes the env is a good hintc
I can run the container flawlessly on vanilla Fedora Core OS (what ostensibly runs OpenShift) and you're saying that it's failing because port 443 is blocked based on the logs. It is not being blocked because of the container, so it has to be something in your environment.
Regular Linux users cannot listen on ports below 1024. To successfully start, simply set the environment variables HTTP_PORT = 8080 and HTTPS_PORT = 8443 :)
Closing as this appears to be an environment issue
Updating the latest image has the same problem, the easiest way to be sure is to use root access:
image: yourimage
user: root
Wow, to run a container not in root is an environment issue?
Is it also an environment issue, if there are no users anymore (just root) ?