Logs not appearing on specified folder

Hello, I’m having issues creating logs for Caddy2, would appreciate some help

1. Caddy version (caddy version):

v2.4.3 h1:Y1FaV2N4WO3rBqxSYA8UZsZTQdN+PwcoOcAiZTM8C0I=

2. How I run Caddy:

sudo systemctl start caddy.service

a. System environment:

systemd, Ubuntu 18.04

b. Command:

c. Service/unit/compose file:

none

d. My complete Caddyfile or JSON config:

notify.ohbarri.com {
	rewrite * /ohbarri/airtable/XXXXXXXXXX?tableName=sell_notifications
	reverse_proxy https://v1.nocodeapi.com {
		header_up Host "v1.nocodeapi.com"
		header_up X-Real-IP {http.request.remote}
		header_up X-Forwarded-For {http.request.remote}
		header_up X-Forwarded-Port {http.request.port}
		#        header_up X-Forwarded-Proto {http.request.scheme}
		transport http {tls}
	}
	log {
		output file /tmp/caddylogs/notification_sell.log {
			roll_size 50mb
			roll_keep 10
			roll_keep_for 720h
		}
	}
}

3. The problem I’m having:

When endpoint is used from the app, no logs appear in /tmp/caddylogs

4. Error messages and/or full log output:

none

5. What I already tried:

Setting up the log { block} as in examples https://caddyserver.com/docs/caddyfile/directives/log#examples

6. Links to relevant resources:

There’s a bunch of problems here. The only line necessary here is header_up Host. Use this instead:

reverse_proxy https://v1.nocodeapi.com {
	header_up Host {http.reverse_proxy.upstream.hostport}
}

When running Caddy with the provided systemd service, /tmp is actually isolated under a different subdirectory, because the service file has the option PrivateTmp=true

What this does is transparently isolate /tmp under a directory like /tmp/systemd-private-<some-hash>-caddy.service-<some-hash>.

Run ls /tmp/systemd* and you should see those directories.

A better location for your logs though, would be /var/log/caddy/notification_sell.log, since the /var/log/caddy directory is automatically created by the apt repo with the correct permissions.

2 Likes

Thanks @francislavoie will give it a try and follow up on the conversation with the results.

Why are the rest of header_up unnecessary out of curiosity?

Sure – so looking at what you had:

See the section on headers in the reverse_proxy docs:

Problems, or things to improve:

  • Using a placeholder for header_up Host is beneficial because it avoids duplication of your hostname in your config.

  • X-Real-IP is not usually used by most applications, X-Forwarded-For is more typically used.

  • Caddy already sets X-Forwarded-For automatically, and more intelligently. The “correct” thing to do is actually to append the remote address to an existing X-Forwarded-For header if it exists, in case some other proxy happened to be in front of Caddy. This doesn’t typically happen, but it can, so best to just let Caddy do its thing.

  • X-Forwarded-Port shouldn’t be necessary. It’s redundant, because Caddy received the request on port 443 and proxied it on port 443. Upstream apps rarely care about this anyways, especially if Caddy is being served over the default HTTP and HTTPS ports, 80 and 443. X-Forwarded-Proto is more useful for the upstream (and Caddy sets this automatically) so that it’s aware that the original request was HTTPS, so it knows to use https:// in URLs in the response.

  • transport http {tls} is not valid syntax. Transports don’t take arguments (i.e. {tls} in this case), but can be configured via options within the block. But in this case, it’s not necessary to configure any of the transport options. Using https:// in your upstream address implicitly tells Caddy to enable tls for the http transport. Also, there’s no such thing as the {tls} placeholder (see the list of Caddyfile placeholder shortcuts – it’s not on that list Caddyfile Concepts — Caddy Documentation). The correct syntax would be the following (but not necessary here as I said because of https://):

    transport http {
    	tls
    }
    

Also to note, if you upgrade to v2.4.5, which is now available, you can shorten it to this:

reverse_proxy https://v1.nocodeapi.com {
	header_up Host {upstream_hostport}
}

We added a new placeholder shortcut to shorten the config a bit. It wasn’t in v2.4.3 yet.

2 Likes

This topic was automatically closed after 30 days. New replies are no longer allowed.