Does import support environment variables?

I’m trying to run two Caddy servers (one bound to IPv4, one to IPv6) from a single Caddyfile (to avoid dual-maintenance). The IPv4 server uses automatic HTTPS/TLS with Let’s Encrypt certificates, the IPv6 server should load said certificates explicitly (to prevent expiry renewal race conditions between the two servers using the same keys).

To achieve this, I need to use an environment variable as part of the import statement to properly form the tls statement in the imported file.

The tls statement in the import file uses placeholders (which I think should be OK), but the import of the file is failing with this:

2016/08/17 13:32:02 /etc/caddy/Caddyfile:13 - Parse error: No files matching import pattern {$ADDRESS}.tls

ADDRESS is defined at startup (and used successfully elsewhere in the Caddyfile for bind), so I can only assume that import’s pattern matcher doesn’t expand variables before matching.

If that’s the case, any suggestions on how I might be able to achieve the same effect?

Thanks,

Rodney

Nope it doesn’t, but it should, so I’ll make that patch soon. Thanks!

Patch confirmed as working, thanks!

However, I wonder if something similar isn’t true (except this time with placeholders instead of envvars) in imported files.

This is the content of the file I’m importing:

tls /etc/ssl/caddy/.caddy/acme/acme-v01.api.letsencrypt.org/sites/{$hostonly}/{$hostonly}.crt /etc/ssl/caddy/.caddy/acme/acme-v01.api.letsencrypt.org/sites/{$hostonly}/{$hostonly}.key

This is the output:

2016/08/18 07:32:19 2001:470:8a59::27.tls:1 - Parse error: Unable to load certificate and key files for ‘www.friendsr.us’: open /etc/ssl/caddy/.caddy/acme/acme-v01.api.letsencrypt.org/sites//.crt: no such file or directory

Aside from vague concerns about the directory structure (as I fear tying the directory path to the upstream cert provider will one day bite someone in the ass), is there any way (short of many variables, which in my use case simply wouldn’t work) to get imports to grok $hostonly?

Rodney

What is your $hostonly environment variable set to?

Nothing at all:

https://caddyserver.com/docs/placeholders

I naively assumed that placeholders were supported by the tls directive - if not, it’s going to make a mess out of trying to refer to the automatic HTTPS certs directly. :confused:

Rodney

Placeholders won’t help you here, their values are obtained from requests and responses, but when Caddy starts there are no requests or responses yet.

Ah - I thought they were derived from the parent of the stanza…bummer.

Back to can’t-get-there-from-here without arbitrary multiple binds. :frowning:

Rodney

Why are you doing this anyway? Caddy will use those without you telling it to, and if you specify them manually it won’t manage them for you.

Since Caddy won’t allow more than one bind, the only way to achieve automatic HTTPS with dual-stack without taking ports 80 and 443 for every interface on the box is to run two instances (preferably from one Caddyfile to avoid dual-maintenance headaches, hence the above) - one for v4 and one for v6.

When doing this, the last thing you want is for both instances of Caddy to try to automatically manage the certs, so the concept was to have the v4 instance auto-manage them and the v6 instance “inherit” them as above.

It may well have been moot, however - it occurred to me that the “inheriting” instance probably won’t notice when the certs are swapped out from underneath it when updated by the managing instance and would have to be manually restarted to pick up the change…also not very clean.

My kingdom for multiple binds… LOL

(As an aside, if multiple binds are ever going to be permitted, I’d like to throw my hat in the ring for requesting considerable flexibility in this regard…and I think I have a pretty common and valid use case for it. If you’re interested, I’ll open another thread to discuss that specific issue.)

Rodney

Okay, right, well definitely don’t do that. You don’t want Caddy instances stepping on each other. We can continue the multiple bind discussion in the issue on GitHub if we want to start taking action on that.

I’ve taken a first stab at a possible configuration description/spec for the Caddyfile, at least, as a comment to the Github issue. It’s by no means perfect, but hopefully it spurs further discussion - I feel pretty passionately that this is -very- important for wider adoption of Caddy (something I would really like to see!).

Rodney

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.