You’ll also need GitHub - mholt/caddy-events-exec: Run commands on Caddy events which provides exec
1 Like
Wow, yep, Francis is right 
and with everything going on / being crazy this weekend I totally missed that in my instructions to you. Sorry!
If you aren’t burned out on this yet, I’d love if you could try that 
I think we’re really, really close to having it working.
2 Likes
Good evening both,
No problem Matt. I’m happy to help and contribute to this project. 
So yes, the good news is that Caddy can now run with the new config.
Bad news is that it didn’t work. The certs are fetched, but nothing fired.
$ root@new-duelify:~# ls -lt /var/lib/caddy/.local/share/caddy/certificates/
drwx------ 4 caddy caddy 4096 Jun 14 21:54 acme-v02.api.letsencrypt.org-directory
caddy.log:
{"level":"info","ts":1686779677.7139874,"logger":"http.acme_client","msg":"authorization finalized","identifier":"*.duelify.com","authz_status":"valid"}
{"level":"info","ts":1686779677.7140584,"logger":"http.acme_client","msg":"validations succeeded; finalizing order","order":"https://acme-v02.api.letsencrypt.org/acme/order/1148859887/188656303127"}
{"level":"info","ts":1686779678.5221033,"logger":"http.acme_client","msg":"successfully downloaded available certificate chains","count":2,"first_url":"https://acme-v02.api.letsencrypt.org/acme/cert/0391c7049f0bfb272111377fdfae5903b1ee"}
{"level":"info","ts":1686779678.522974,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"*.duelify.com"}
{"level":"info","ts":1686779678.5233765,"logger":"tls.obtain","msg":"releasing lock","identifier":"*.duelify.com"}
{"level":"error","ts":1686779678.5305665,"logger":"events.handlers.exec","msg":"background command failed","error":"exit status 1"}
{"level":"info","ts":1686779678.6759813,"logger":"http.acme_client","msg":"successfully downloaded available certificate chains","count":2,"first_url":"https://acme-v02.api.letsencrypt.org/acme/cert/031ad7ecad359edf060c7f05cc5ad78f170d"}
{"level":"info","ts":1686779678.6766348,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"duelify.com"}
{"level":"info","ts":1686779678.676871,"logger":"tls.obtain","msg":"releasing lock","identifier":"duelify.com"}
{"level":"error","ts":1686779678.6850147,"logger":"events.handlers.exec","msg":"background command failed","error":"exit status 1"}
I’m sharing my whole config, maybe I missed something:
{
"logging": {
"logs": {
"default": {
"writer": {
"filename": "/var/log/caddy/caddy.log",
"output": "file",
"roll_keep": 5,
"roll_keep_days": 30,
"roll_size_mb": 954
}
}
}
},
"apps": {
"events": {
"subscriptions": [
{
"events": [
"cert_obtained"
],
"handlers": [
{
"handler": "exec",
"command": "cp",
"args": ["{event.data.storage_path}/*", "/home/xray/tls2/"]
}
]
}
]
},
"http": {
"servers": {
"srv0": {
"listen": [
"127.0.0.1:5005"
],
"listener_wrappers": [
{
"wrapper": "proxy_protocol"
}
],
"routes": [
{
"handle": [
{
"handler": "headers",
"response": {
"set": {
"Strict-Transport-Security": [
"max-age=31536000; includeSubDomains; preload"
]
}
}
},
{
"handler": "file_server",
"root": "/srv/http/default"
}
]
}
],
"protocols": [
"h1",
"h2c"
]
},
"srv1": {
"listen": [
":80"
],
"routes": [
{
"handle": [
{
"handler": "static_response",
"headers": {
"Location": [
"https://{http.request.host}{http.request.uri}"
]
},
"status_code": 301
}
]
}
]
}
}
},
"tls": {
"certificates": {
"automate": [
"duelify.com",
"*.duelify.com"
]
},
"automation": {
"policies": [
{
"issuers": [
{
"module": "acme",
"email": "info@domn.com",
"challenges": {
"dns": {
"provider": {
"name": "cloudflare",
"api_token": "{env.CLOUDFLARE_API_TOKEN}"
}
}
}
},
{
"module": "zerossl",
"email": "info@domn.com",
"challenges": {
"dns": {
"provider": {
"name": "cloudflare",
"api_token": "{env.CLOUDFLARE_API_TOKEN}"
}
}
}
}
]
}
]
}
}
}
}
1 Like
Awesome!! Thanks!
So in the logs it looks like it did fire, but it failed:
{"level":"error","ts":1686779678.6850147,"logger":"events.handlers.exec","msg":"background command failed","error":"exit status 1"}
Hmm, and the command’s output (stdout and stderr) is passed through to Caddy’s stdout/stderr. Do you capture that at all?
(We don’t capture it in logs because the output could be unwieldy. Like really big. So we just pass through the stream, which is efficient.)
Ah sorry, it was late at night. What I meant was it fired, but failed to execute. Permission shouldn’t be a problem because that folder has group read and write access for the Caddy user. So it’s a bit of a mystery.
"logging": {
"logs": {
"default": {
"writer": {
"filename": "/var/log/caddy/caddy.log",
"output": "file",
"roll_keep": 5,
"roll_keep_days": 30,
"roll_size_mb": 954
}
}
}
},
I only capture the logs like this. There is also /var/log/caddy/error.log but there is nothing useful.
Do you know how I could capture stdout and stderr separately for Caddy to see the issue?
I couldn’t see anything in the syslog either.
1 Like
Systemd (journald, I guess) should capture the stdout/stderr for you 
If it’s not, then I don’t know why…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.