Closed wrenix closed 3 months ago
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
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 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) ?
Supporting Details Provide the following:
Describe the bug
Problems: