httpcaddyfile: Allow hostnames & logger name overrides for log directive
#5643
Conversation
francislavoie
force-pushed
the
log-hostname-override
branch
3 times, most recently
from
27e3838 to
7c2cf6f
Compare
francislavoie
changed the title
hostname override for log directivehostnames override for log directive
|
relevant thread surrounding the rationale for this feature |
|
Say there are two log directives *.example.com {
log {
output file /var/log/caddy/access.log
}
log {
hostnames foo.example.com
output file /var/log/caddy/foo.example.com.log
}
@foo host foo.example.com
handle @foo {
respond "foo"
}
@foo host bar.example.com
handle @bar {
respond "bar"
}
}do the logs for 'foo' end up in both the access.log and the foo.example.com.log? to me it always made more sense to try and nest the log directive inside the handle function, that way any request that ends up inside the handle function instead gets logged in a separate way, overriding the logging strategy defined in the parent. That way logs for undefined/unexpected hostnames end up in the access.log, and the defined hostnames each get a logfile. my intuitive first guess on how this could work, before realizing it threw an error was *.example.com {
log {
output file /var/log/caddy/access.log
}
@foo host foo.example.com
handle @foo {
respond "foo"
log {
output file /var/log/caddy/foo.example.com.log
}
}
@foo host bar.example.com
handle @bar {
respond "bar"
log {
output file /var/log/caddy/bar.example.com.log
}
}
}requests to foo.example.com end up in foo.example.log A practical reason for a setup like this would be to deliberately search for out of place http requests targeted at hosts that don't or no longer exist and block the IPs associated with such abusive requests. So, even if the |
Good question. It won't, no, only the most specific logger; i.e. if there's a logger for Since your site block's address is
Yeah I wish we could do that. It's not possible though. The problem is that For example, If you run In Caddy v3 or whatever, we might redesign how logging is configured. But that's still far away. |
|
SGTM thanks for the explanation. I think an alternate solution to this problem that could ease complexity would be to enforce wildcard TLS for a given domain name at the server level, but given how the docs guide people to use this format with wildcard domains, this implementation makes sense. |
|
Yeah there's some ideas about that in #5447 |
francislavoie
force-pushed
the
log-hostname-override
branch
from
7c2cf6f to
aae2ada
Compare
|
After playing around with the question in https://caddy.community/t/multiple-access-logs-in-site-block-only-last-defined-works/20599, I added a second commit to this branch adding another feature; overriding the logger name with the In practice, the only time this should be useful I think is to have 2 separate outputs for a single access log source. But also it gives slightly more control over JSON output if that matters at all for users (99.9% of the time it shouldn't). It was mostly trivial, but I had to adjust a few things to cover some edgecases. |
francislavoie
changed the title
hostnames override for log directivehostnames & logger name override for log directive
francislavoie
changed the title
hostnames & logger name override for log directivehostnames & logger name overrides for log directive
|
Thanks for working on this. Do you want me to get this in 2.7 (might need some more time to review) or can it wait until after 2.7? |
francislavoie
force-pushed
the
log-hostname-override
branch
from
aae2ada to
017d63a
Compare
|
It could wait, but also it's not that complex so if we could squeeze it in that'd be cool too. |
|
Reference: https://caddy.community/t/multiple-access-logs-in-site-block-only-last-defined-works/20599/7 I have used the feature to override the logger name from this PR and it works fine. But when the The Caddyfile used here was: Go version is
|
francislavoie
force-pushed
the
log-hostname-override
branch
from
017d63a to
5b4dceb
Compare
francislavoie
force-pushed
the
log-hostname-override
branch
from
5b4dceb to
3c0677f
Compare
|
Should be fixed now @steffenbusch if you'd like to try again and confirm. |
|
Great! Thank you @francislavoie. @steffenbusch we might release Caddy 2.7 tomorrow, especially if you can confirm it works for you 😃 |
|
Thank you very much @francislavoie and @mholt. |
|
Awesome, thank you! |
I've been thinking about this for a while. We've had a few cases where users ask to be able to configure logging per subdomain when using a wildcard site block (i.e. this pattern https://caddyserver.com/docs/caddyfile/patterns#wildcard-certificates).
Normally, the
logdirective auto-detects the hostname to use from the site block's names. So if you define aloginside*.example.com, it will map*.example.comtolog0(or whatever auto-increment ID you get for that logger name if not0).It's always been possible to define more than one
logdirective inside of a site block, we didn't prevent it; but it wasn't very useful to do, because then you'd just be writing access logs to two different places which is usually not what you want.So making use of the above, we can add a new
hostnamesoption to thelogdirective that overrides the auto-detection for that logger and specifically only logs for those hostnames. This makes it easy to setup one log file per subdomain, while still using a wildcard cert.Here's a full Caddyfile example (except for
tlsand fallbackhandlethat you'd typically want as per the pattern linked above):I'd recommend using snippets to make this shorter because it would make it possible to avoid repeating the domain for both the logger and host matcher. I'll probably write up an example for the docs that does that.
Edit: I changed it from
hostnametohostnamesbecause I realized "why not allow a logger to log more than one subdomain". It aligns better with the fact that site blocks are a list of hosts and not just a single one, so both approaches take a list. Slightly more flexible, but I expect the vast majority of users will be just configuring one hostname, if they want to override at all. The adapter test covers both.