Recreating ddns_caddy_1 error

[luisBSBDATA]

Hi!

When I run docker-compose --project-name ddns up -d --build I get those error messages:

Thanks in advance!

[pboehm]

Hi,

without knowing anything about your setup (looking at the terminal font and all the backslashes in the screenshot, it is probably a Windows system?) the error probably refers to the following line in the docker-compose.override.yml https://github.com/pboehm/ddns/blob/master/docker/docker-compose.override.yml.sample#L27 where the Caddyfile is mounted into the caddy container.

If your setup is a Windows system the problem probably has something to do with paths, like the following issue docker/compose#4303.

Please provide more information about your setup.

Philipp

[luisBSBDATA]

Hi,

It's actually an Ubuntu Server 16.04 completely up to date. Docker is not running anything more than the ddns container. Docker and docker-compose versions are 1.21.2.

[pboehm]

Okay, could you provide your docker-compose.override.yml and please redact any sensitive data.

[luisBSBDATA]

Sure, here it is:

[pboehm]

Hi,

sorry for my late reply. Your docker-compose.override.yml looks okay for me. Looking at the original error message ... mounting /caddy/Caddyfile ......, the problem seems to be that the ${PWD} has not contained the current working directory but was empty https://stackoverflow.com/questions/41948232/docker-compose-wont-find-pwd-environment-variable?rq=1 . Could you try replacing ${PWD} with a ., this hopefully solves the problem.

[luisBSBDATA]

Hi,

Now the error is gone but I cannot access the fronted webpage nor curl it from the LAN or from the same server (127.0.0.1).

Thank you for your (quick) support!

[pboehm]

Ok, cool that the original problem is solved. For the other problem the output of the caddy container would be interesting because after startup it tries to gather a TLS certificate for the configured domain. Until this process is successful, caddy probably does not serve the frontend code or responds to curl. If the errors are more low-level like "connection refused", it probably has something to do with some firewall rules or that the docker port-forwarding for port 80 and 443 are bound to the wrong network interface. In this case you have to provide some more information like the output of netstat -tulpen.

[luisBSBDATA]

Oh, if it tries to gather a TLS certificate from lets-encrypt it's necessary to have the ports open from the beginning right? I was testing it locally to make sure all was working as expected and I was going to open the ports later. I will open the ports and stuff and try, then I will tell you how it went. Again, thank you for your support!

[luisBSBDATA]

One last question, can I use my own certificates instead of using lets-encrypt? That would be easier as our servers are all proxied.

[pboehm]

The Caddy webserver is totally optional and is only included in the docker-compose.override.yml sample to provide a working out-of-the-box setup. But you can remove it and use nginx as a reverse proxy (make sure that the X-Forwarded-For header is included, so that the real remote address is available to ddns) or you could configure Caddy to take your certificate which should be possible, but I haven't used it.

[luisBSBDATA]

The Caddy webserver is totally optional and is only included in the docker-compose.override.yml sample to provide a working out-of-the-box setup. But you can remove it and use nginx as a reverse proxy (make sure that the X-Forwarded-For header is included, so that the real remote address is available to ddns) or you could configure Caddy to take your certificate which should be possible, but I haven't used it.

Sorry, those last months were extremely busy and I haven't had time to play more time with it. How can I configure Caddy to take my own certificates instead of using Let's Encrypt? I know how to do it in a normal Caddy installation but not within the docker environment.

[pboehm]

This normally consists of adding the local directory containing the certificates to the caddy container by declaring another volume like here https://github.com/pboehm/ddns/blob/master/docker/docker-compose.override.yml.sample#L27. You could add something like /local/path/to/certs:/etc/caddy-certs to the volumes list in the caddy container. Within the caddy container you then have access to these certificates and can reference them in the Caddyfile e.g via /etc/caddy-certs/cert.pem.

[luisBSBDATA]

This normally consists of adding the local directory containing the certificates to the caddy container by declaring another volume like here https://github.com/pboehm/ddns/blob/master/docker/docker-compose.override.yml.sample#L27. You could add something like /local/path/to/certs:/etc/caddy-certs to the volumes list in the caddy container. Within the caddy container you then have access to these certificates and can reference them in the Caddyfile e.g via /etc/caddy-certs/cert.pem.

I just did it and the docker container got built perfectly, but I cannot access the frontend when I point my browser to my server private IP just like when it was using let's encrypt. Where can I find the Caddy logs so I can check whats going on?

EDIT: I just figured out how to check them and it seems like is working as expected (port 2015 is normal?):

Also here it is the list of running containers and it's ports in case it helps:

[pboehm]

This port 2015 seems to be a caddy default when it doesn't manages the TLS certificates itself and no https:// is used in the Caddyfile. There are multiple issues in the Caddy repo like the following caddyserver/caddy#1673. You could probably fix this via the Caddyfile or you could map your external 443 port to 2015 inside the caddy container. I hope that it helps.

[luisBSBDATA]

This port 2015 seems to be a caddy default when it doesn't manages the TLS certificates itself and no https:// is used in the Caddyfile. There are multiple issues in the Caddy repo like the following mholt/caddy#1673. You could probably fix this via the Caddyfile or you could map your external 443 port to 2015 inside the caddy container. I hope that it helps.

I mapped the external 443 to the internal 2015 and it worked fine, thanks for that. Now I'm stuck into no getting any response when I ping a host created using the frontend. I can curl the URL fine and I get the response, but if I ping the host (something.d.domain.com) it times out.

I tried connecting to port 53 UDP using netcat from the outside and it works so PowerDNS is listening.. I don't know how to move forward, any help is appreciated.

[pboehm]

If you create a host via the frontend a curl command is printed and this has to be executed from inside the network that you wanna access through the registered name. If you can successfully resolve the registered name via dig or nslookup ddns works correctly and the problem ist somewhere else.

dig something.d.somewhere.com A @8.8.8.8

You can control which DNS server should be used via the @x.x.x.x.

[luisBSBDATA]

If you create a host via the frontend a curl command is printed and this has to be executed from inside the network that you wanna access through the registered name. If you can successfully resolve the registered name via dig or nslookup ddns works correctly and the problem ist somewhere else.

dig something.d.somewhere.com A @8.8.8.8

You can control which DNS server should be used via the @x.x.x.x.

Working as expected. There was something to do with our reverse proxy, I changed the server WAN to another without proxying it and now it's alright.

The only thing isn't working for me is customizing template.go. If I change what I want and rebuild the docker containers the changes aren't visible. Looks like it pulls the image from a repo instead of using the offline files?

[pboehm]

No it doesn't fetch something from a repo. docker-compose run does not rebuild the containers by itself docker/compose#1487 so you have to explicitly build the containers via docker-compose build and remove the old containers via docker-compose down before executing the run command from the docs again.

Feel free to close this issue if you problems have now been solved.

[luisBSBDATA]

Thank you @pboehm, superb support from your part