Hi, here’s the config - sorry for missing the first request, I was racing the clock in my time-zone before end-of-day and I’ve been trying to make progress on this all day. Frustrating times but I do appreciate the help.
Note the log-level in log0 - since changing this to “DEBUG” I have not noticed any difference in the actual output, I’m still only seeing errors. Perhaps it belongs elsewhere in the logs object?
{
"logging": {
"logs": {
"default": {
"exclude": [
"http.log.access.log0"
]
},
"log0": {
"level": "DEBUG",
"writer": {
"filename": "/opt/caddy/access.log",
"output": "file"
},
"include": [
"http.log.access.log0"
]
}
}
},
"apps": {
"http": {
"servers": {
"srv0": {
"listen": [
":443"
],
"routes": [
{
"match": [
{
"host": [
"social.domaín.ie",
"social.xn--doman-2sa.ie",
"epicyon.domaín.ie",
"epicyon.xn--doman-2sa.ie"
]
}
],
"handle": [
{
"handler": "subroute",
"routes": [
{
"handle": [
{
"handler": "reverse_proxy",
"headers": {
"request": {
"set": {
"Host": [
"=?utf-8?b?<redacted>?="
]
}
}
},
"upstreams": [
{
"dial": "localhost:7156"
}
]
}
]
}
]
}
],
"terminal": true
}
],
"logs": {
"logger_names": {
"epicyon.domaín.ie": "log0",
"epicyon.xn--doman-2sa.ie": "log0",
"social.domaín.ie": "log0",
"social.xn--doman-2sa.ie": "log0"
}
}
}
}
},
"tls": {
"automation": {
"policies": [
{
"subjects": [
"epicyon.domaín.ie",
"epicyon.xn--doman-2sa.ie",
"social.domaín.ie",
"social.xn--doman-2sa.ie"
],
"issuers": [
{
"email": "<redacted>",
"module": "acme"
},
{
"email": "<redacted>",
"module": "zerossl"
}
]
}
]
}
}
}
}
Aside on Docs Comprehensibility
Take this with “a pinch of salt” because it could just be me and my brain.
As far as the issues with the JSON docs: with time I’m sure I could get used to the layout and find it elegant, but when I’m just looking up “where do I put my email for the acme providers”, it can be hard to get that answer. The email field might be presented as a field in an object which is documented on the page I found… but where does that object go? The “at a glance” view of config nesting doesn’t provide as much info as it could… a well-documented example containing all the supported fields, perhaps with the defaults, might help. And where sub-objects are being documented, a clearer impression of their ‘path’ in the root JSON object might help, too.
I think there’s also something fundamentally harder to document about JSON: it’s far more verbose, especially if pretty-printed, and it doesn’t support any comment, so examples have to be presented in fragmentary form to be brief, but then they lack the useful context. With Caddyfiles it was possible to document things by having examples that were documented in-line using comments, and the brevity of the caddyfile meant you could usually see the prelude and maybe the postmatter of the documented example all on one screen.
My workflow so far has been to try and get the fields I need in the caddyfile, convert them, and note where they end up in the resulting JSON. Then I revert to the docs for further guidance once I know where to put things. Sometimes when not many examples exist to copy, like setting “DEBUG” loglevel, I try to figure out where to put the line from the JSON-only docs and it crashes quickly if the config is wrong…