Long way too go... unable to install caddy custom

[hackaro]

@TheRettom

I’m trying to recall everything, and re-reading previous posts isn’t helping. So I’m trying to get this straight. Is 109.54.22.237 the IP address to the LTE 4G?

Yes, correct. At the moment the network topology is as follow:

LTE 4G dongle WAN: 109.54.164.150
LTE 4G dongle LAN: 192.168.0.1
FRITZ!BOX WAN (even if it’s connected by USB port to the dongle): 192.168.0.x (DHCP related)
Fritz!Box LAN: 192.168.2.1

And Dynu gets the Fritz!Box WAN Ip address in its DNS records because the Fritz!Box is still working by the way of an LTE dongle which creates its own routing. And this is wrong, because Dynu should see the actual WAN address of my LTE dongle, hence the dongle is not working as expected here because I haven’t supposed it has its own routing capabilities.

At this point I don’t know how to connect directly the Fritz!Box to Internet without passing by a routing device.

@TheRettom

So the command didn’t fix it? It should. Usually the problem lies with the spacing in the Caddyfile, as Tab should be used for long spaces instead of Spacebar x however many times you used.

No, I guess the command did fix it. In fact I haven’t seen the same error in logs: Caddyfile seems to be correct at the moment. Nevertheless Caddy cannot work properly because Dynu services are not able to reach the Caddy Web server properly, I guess.

@TheRettom

This is one of many reasons why Caddy is awesome. The Dynu plugin, and your configuration, should automatically handle SSL certificates for your domains in the site blocks.

{
    acme_dns dynu mydynu_token
}

Caddy can also handle DynamicDNS if you get the plugin. You’d add to your global config so it would look like this:

{
	acme_dns dynu (your dynu token)
	dynamic_dns {
		provider dynu (your dynu token)
		domains {
			tilde.mywire.org
		}
	}
}

---

Ok, I have tried different Caddyfile:

{
acme_dns dynu mydynutoken
}
https://tilde.mywire.org {
        respond "Hello!"
        file_server
}

which is pretty simple, BUT the log I get is:

sudo docker logs -n 10  caddy
{"level":"info","ts":1740854903.5814257,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Error: adapting config using caddyfile: parsing caddyfile tokens for 'acme_dns': missing own domain, at /etc/caddy/Caddyfile:2
{"level":"info","ts":1740854904.0917075,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Error: adapting config using caddyfile: parsing caddyfile tokens for 'acme_dns': missing own domain, at /etc/caddy/Caddyfile:2
{"level":"info","ts":1740854904.6337993,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Error: adapting config using caddyfile: parsing caddyfile tokens for 'acme_dns': missing own domain, at /etc/caddy/Caddyfile:2
{"level":"info","ts":1740854905.3262904,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Error: adapting config using caddyfile: parsing caddyfile tokens for 'acme_dns': missing own domain, at /etc/caddy/Caddyfile:2
{"level":"info","ts":1740854906.4114118,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Error: adapting config using caddyfile: parsing caddyfile tokens for 'acme_dns': missing own domain, at /etc/caddy/Caddyfile:2

any hint? Can I do the same with a JSON config file? it seems simpler in structure to me, provided that I can mix it with Caddyfile, which is very easy to modify.

@TheRettom

Syncthing is what I plan on switching to when I need files, as I haven’t yet needed it. If you don’t care if something is made by the Chinese, Seafile will be good. I don’t want to go on a long tangent, but I find China, and especially Chinese IT hardware and software, to be extremely dangerous. It’s mostly open source. By that, I mean features are proprietary, but I believe it’s only for professional/licensed versions. Regardless, it being open-source for the base image usually indicates it’s safe, but I don’t understand coding languages enough to confirm. It’s written with C and Python.

Well… SeaFile seems to be promising as it can be use from mobile app too, I will evaluate, thanks!

[TheRettom (Riley M)]

@hackaro

And Dynu gets the Fritz!Box WAN Ip address in its DNS records because the Fritz!Box is still working by the way of an LTE dongle which creates its own routing. And this is wrong, because Dynu should see the actual WAN address of my LTE dongle, hence the dongle is not working as expected here because I haven’t supposed it has its own routing capabilities.

Right. I just want to verify. You have LTE 4G dongle WAN forwarding port 80 and 443 traffic to the FRITZ!BOX WAN, correct? In DHCP settings, you should give that WAN a static IP so it won’t change on you. Then on the FRITZ!BOX, set up port forwarding for 80 and 443 to the NUC. If that still isn’t working, then that’s beyond me, unfortunately. You should create a post in a networking forum where people are smarter than me by far.

---

@hackaro

Error: adapting config using caddyfile: parsing caddyfile tokens for 'acme_dns': missing own domain, at /etc/caddy/Caddyfile:2

any hint? Can I do the same with a JSON config file? it seems simpler in structure to me, provided that I can mix it with Caddyfile, which is very easy to modify.

Yeah. Caddy’s module for Dynu lists what is needed. You have to add this to it as well, but I forgot to in my example. Sorry.

own_domain should be set to the root domain returned from /dns/getroot/{hostname} of the Dynu API. For example, if you have a subdomain my.dynu.com, this should be set to my.dynu.com so that the correct hostname is used to update Dynu. This is needed as the zone used by Caddy DNS challenge is different from the subdomain provided by Dynu.

	acme_dns dynu yourtoken {
		own_domain {env.OWN_DYNU_DOMAIN}
	}

If it’s still giving you problems about the token, then add it as referenced in the link. And yes, you can use JSON if you want.

[hackaro]

@TheRettom

own_domain should be set to the root domain returned from /dns/getroot/{hostname} of the Dynu API. For example, if you have a subdomain my.dynu.com, this should be set to my.dynu.com so that the correct hostname is used to update Dynu. This is needed as the zone used by Caddy DNS challenge is different from the subdomain provided by Dynu.

	acme_dns dynu yourtoken {
		own_domain {env.OWN_DYNU_DOMAIN}
	}

If it’s still giving you problems about the token, then add it as referenced in the link

ok, now my Caddyfile is as follow:

acme_dns dynu mydynutoken
	{
	own_domain {tilde.mywire.org}
	}

https://tilde.mywire.org {
        respond "Hello!"
        file_server
}

but I still get errors from parsing:

{"level":"info","ts":1741079224.3791897,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Error: adapting config using caddyfile: /etc/caddy/Caddyfile:3: unrecognized directive: own_domain
Did you mean to define a second site? If so, you must use curly braces around each site to separate their configurations.

why doesn’t it recognise correctly the own_domain directive?
More: the env. prefix means environment variable, right? So where and how should I create it?

@TheRettom

If it’s still giving you problems about the token, then add it as referenced in the link. And yes, you can use JSON if you want.

ok, but while Caddyfile is exposed outside the container, where can i find(or put) the JSON config file?

[TheRettom (Riley M)]

@hackaro

but I still get errors

My apologies, I should have been more clear since you’re somewhat new to this. Everything should be exactly as it shows below except for replacing your_token_here with your actual token string. So you should just copy/paste and replace the token.

{
        acme_dns dynu your_token_here {
                own_domain tilde.mywire.org
        }
}

tilde.mywire.org {
        respond "Hello!"
        file_server
}

---

@hackaro

why doesn’t it recognise correctly the own_domain directive?

That’s because of the way you formatted the block ({ and }), or lack thereof. acme_dns is a global option and should be the first block.

---

@hackaro

More: the env. prefix means environment variable, right? So where and how should I create it?

Yes, since it’s in a block and it starts with env. You’d add the environmental variable DYNU_API_TOKEN to your compose.yaml. And if you wanted to, you could also add OWN_DYNU_DOMAIN. So both would look like:

services:
  caddy:
    container_name: caddy
    image: caddy:latest
    restart: unless-stopped
    environment:
    - "TZ=Europe/Rome"
    - "DYNU_API_TOKEN=your_token_string"
    - "OWN_DYNU_DOMAIN=tilde.mywire.org"
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
        - "/srv/caddy/caddy:/usr/bin/caddy"
        - "/srv/caddy/caddy-config.json:/etc/caddy/caddy-config.json"
        - "./site:/srv"
        - "/srv/caddy/data:/data"

---

@hackaro

Caddyfile is exposed outside the container, where can i find(or put) the JSON config file?

I believe you’d just replace your bind of /srv/caddy/Caddyfile:/etc/caddy/Caddyfile to something like /srv/caddy/caddy-config.json:/etc/caddy/caddy-config.json and then add command: ["caddy", "run", "--config", "/etc/caddy/caddy-config.json"] to your compose.yaml like so:

services:
  caddy:
    container_name: caddy
    image: caddy:latest
    restart: unless-stopped
    environment:
    - "TZ=Europe/Rome"
    - "DYNU_API_TOKEN=your_token_string"
    - "OWN_DYNU_DOMAIN=tilde.mywire.org"
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
        - "/srv/caddy/caddy:/usr/bin/caddy"
        - "/srv/caddy/caddy-config.json:/etc/caddy/caddy-config.json"
        - "./site:/srv"
        - "/srv/caddy/data:/data"
    command: ["caddy", "run", "--config", "/etc/caddy/caddy-config.json"]

You could also translate your Caddyfile to JSON. My opinion is Caddyfile is best, but I’m biased because I don’t make JSONs from scratch.

[hackaro]

ok, I have good news… Partially! LOL !

First I’m pretty happy because I’ve finally solved the matter of addressing correctly Dynu’s DDNS with my router. The solution has been pretty simple: I’ve adopted another container that makes the DDNS update, you can find it here.

I was able to correctly create the docker compose file and create an instance of it which is running on my NUC. Pretty happy about that!

And in fact I get:

Then I was also able to correctly open the 80 and 443 ports of my mobile router:

So Caddy should work now but, guess what? It doesn’t!

Ok, here I digress for a moment because I’d like to know if I understood correctly.
Caddy usually uses CA from Let’s Encrypt which has two services, one for staging and one for production. The one for staging is there just because it gives the chance to try your configuration and doesn’t block you if you make too many mistakes. Which is probably my case! LOL!

when I used the directive acme_dns it’s because I want to use the DNS challenge and NOT the HTTPS one. That’s because I want to use as many subdomains as I want without restrictions, as I read here:

@matt

With that, Caddy will serve all direct subdomains of example.com using a single wildcard certificate. Oh, but check your ACME CA’s policies about issuing wildcard certificates. At time of writing, some CAs like Let’s Encrypt only issue wildcard certificates using the DNS challenge.

Now in fact what I get in the logs is:

{"level":"error","ts":1741277241.923372,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"tilde.mywire.org","issuer":"acme-staging-v02.api.letsencrypt.org-directory","error":"HTTP 403 urn:ietf:params:acme:error:unauthorized - During secondary validation: No TXT record found at _acme-challenge.tilde.mywire.org"}
{"level":"error","ts":1741277241.923496,"logger":"tls.obtain","msg":"will retry","error":"[tilde.mywire.org] Obtain: [tilde.mywire.org] solving challenge: tilde.mywire.org: [tilde.mywire.org] authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - During secondary validation: No TXT record found at _acme-challenge.tilde.mywire.org (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":7.429886971,"max_duration":2592000}

And some lines refer specifically to a TXT field to be put in DNS records, as I read here I should put that record at _acme-challenge.<YOUR_DOMAIN> . But there is … a but! As free user of Dynu’s services I cannot create any TXT record in my DNS zone… so I’m trying to understand if there is another way or if I have to pay to get what I want.

PS: thanks so much for all the explanations of your previous reply, I’ve learnt a lot of stuff!

[TheRettom (Riley M)]

@hackaro

First I’m pretty happy because I’ve finally solved the matter of addressing correctly Dynu’s DDNS with my router. The solution has been pretty simple: I’ve adopted another container that makes the DDNS update, you can find it here.

Interesting. I don’t see how that container would be doing anything differently. The coding essentially works the same from what I see. What were the Caddy logs when trying it?

---

@hackaro

Ok, here I digress for a moment because I’d like to know if I understood correctly.
Caddy usually uses CA from Let’s Encrypt which has two services, one for staging and one for production. The one for staging is there just because it gives the chance to try your configuration and doesn’t block you if you make too many mistakes. Which is probably my case! LOL!

Aye, laddy. The log you are showing me has:

"issuer":"acme-staging-v02.api.letsencrypt.org-directory"

Assuming it’s been a while since you’ve tried getting it with Caddy, you should get the non-staging issuer. If not, based on what I’m reading, add this to the global block:

        acme_ca https://acme-v02.api.letsencrypt.org/directory

The default directory is https://caddyserver.com/docs/caddyfile/directives/tls#dir as listed here. The acme_ca global option will let us point it there.

---

@hackaro

when I used the directive acme_dns it’s because I want to use the DNS challenge and NOT the HTTPS one. That’s because I want to use as many subdomains as I want without restrictions

Yep, using the tls dns directive, or in our case for global options acme_dns, disables http and tls-alpn by default.

---

@hackaro

And some lines refer specifically to a TXT field to be put in DNS records, as I read here I should put that record at _acme-challenge.<YOUR_DOMAIN> . But there is … a but! As free user of Dynu’s services I cannot create any TXT record in my DNS zone… so I’m trying to understand if there is another way or if I have to pay to get what I want.

Didn’t know that. Not gord. If you cannot create a TXT record, then you cannot do DNS challenges. If you still want to use a free service, DuckDNS is a viable alternative with its own plugin. Otherwise, purchasing a cheap domain is what I recommend.

I used DuckDNS for about a year before deciding I want to try my own domain. Well worth it in my opinion. DuckDNS is good for what it is, and the guys who made and maintain it are saints.

---

@hackaro

PS: thanks so much for all the explanations of your previous reply, I’ve learnt a lot of stuff!

Yessir. It takes a lot to go from beginner to novice, and it’s not easy to have that done on the internet. I learned through trial and error mostly.

[hackaro]

ok, sorry for the delay but I had really hectic days.

@TheRettom

Interesting. I don’t see how that container would be doing anything differently. The coding essentially works the same from what I see. What were the Caddy logs when trying it?

The Caddy srv has always been worked with the IP provided by Dynu which was wrong, as I said in some of my previous messages. With this container, instead, the IP is taken correctly.

But another problem arises, the public IP is passed correctly but my mobile (as I’m temporarily working with an LTE router) network is natted. And this has another bad implication: ports 80 and 443 are closed by my ISP. So, no luck here!

@TheRettom

Didn’t know that. Not gord. If you cannot create a TXT record, then you cannot do DNS challenges. If you still want to use a free service, DuckDNS is a viable alternative with its own plugin. Otherwise, purchasing a cheap domain is what I recommend.

IN the meantime, I’ve decided to change the DNS provider myself. So I went with Cloudflare because there are plenty of documentation on how things must be getting done right with CF. And I bought with them a domain that - I hope - I will use as soon as I can use a public IP on a normal FFTH service. I’m also giving a try to Traefik, because I’d like to understand if it’s simpler to use.

Thanks so much for now!

[TheRettom (Riley M)]

@hackaro

But another problem arises, the public IP is passed correctly but my mobile (as I’m temporarily working with an LTE router) network is natted. And this has another bad implication: ports 80 and 443 are closed by my ISP. So, no luck here!

Yikes. Sorry to hear that.

---

@hackaro

IN the meantime, I’ve decided to change the DNS provider myself. So I went with Cloudflare because there are plenty of documentation on how things must be getting done right with CF. And I bought with them a domain that - I hope - I will use as soon as I can use a public IP on a normal FFTH service. I’m also giving a try to Traefik, because I’d like to understand if it’s simpler to use.

Cool. Cloudflare is useful in certain applications, and yours may be one of them. Hope your have a good experience with their domain/DNS services.

I don’t know too much about Traefik, but from what I have seen, it is similarly easy like Caddy. By this point, it would be hard to remove my bias of Caddy, but I strongly believe the documentation between Traefik and Caddy shows that Caddy is superior. It has vastly more detail and configuration examples. The configuration of plugins appears to require more config knowledge and adaption.

The plugin list appears somewhat comparable to Caddy, but lots of them do not appear to be coded by Traefik’s team in any regard. Is that a problem? Maybe not, but I feel Caddy’s set of plugins are highly vetted by experienced programmers, and lots of them have direct involvement with Matt, the creator of Caddy. Many community members that help with Caddy’s development are very knowledgeable and experienced with Go.

Again, I likely have bias, but I think Caddy is more mature and the Caddyfile structure is super easy. I highly encourage you to try Traefik to see if it fits you better, but I would honestly expect you would just come back to Caddy.