caddy validate fail as unprivileged user since 2.9.0, when using a privileged log path

[oxalica]

Given Caddyfile:

localhost {
    log {
        output file /var/log/caddy/access.log
    }
}

Running caddy validate ./Caddyfile as an unprivileged user succeeds with caddy 2.8.4, but fails for both 2.9.0 and 2.9.1. Error message:

2025/01/13 22:47:21.838 INFO    using adjacent Caddyfile
2025/01/13 22:47:21.838 INFO    using config from file  {"file": "Caddyfile"}
2025/01/13 22:47:21.838 INFO    adapted config to JSON  {"adapter": "caddyfile"}
2025/01/13 22:47:21.838 WARN    Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies    {"adapter": "caddyfile", "file": "Caddyfile", "line": 2}
Error: setting up custom log 'log0': opening log writer using &logging.FileWriter{Filename:"/var/log/caddy/access.log", Mode:0x0, Roll:(*bool)(nil), RollSizeMB:0, RollCompress:(*bool)(nil), RollLocalTime:false, RollKeep:0, RollKeepDays:0}: mkdir /var/log/caddy: permission denied

Expected behavior: Exit with 0 successfully and never try to create or modify the log file path. caddy validate should be a "dry run".

Use case: I'm using caddy validate in a NixOS builder sandbox to check the validity (syntax, typo on option names and etc) before deploying to the production server. So I want it to be relatively easy to do the check in a developing environment, without the need to setup a production-compatible environment.

I guess it's caused by #6314 ? cc @ririsoft

[mholt]

Expected behavior: Exit with 0 successfully and never try to create or modify the log file path. caddy validate should be a "dry run".

Well, part of the validation is to ensure that the config will load and run successfully. So ignoring errors would defeat the purpose. If we ignore that error, your config won't work when you go to run it.

[oxalica]

Expected behavior: Exit with 0 successfully and never try to create or modify the log file path. caddy validate should be a "dry run".

Well, part of the validation is to ensure that the config will load and run successfully. So ignoring errors would defeat the purpose. If we ignore that error, your config won't work when you go to run it.

So you mean mkdir during validation is the expected behavior? This seems quite intrusive to me.
But if so, is there any other way to check the syntax and option typo locally, without giving access to remote production paths (/var/lib, /var/www, SSL certificates and etc)?

[mholt]

Yes, again; the point of validate is to ensure that when you go to run your server, it has the highest likelihood of running successfully. Since it will have to have a place to write the log files, it needs to have the directory for them.

But if so, is there any other way to check the syntax and option typo locally, without giving access to remote production paths

If you only want to verify your config syntax, use caddy adapt.

[Stunkymonkey]

@mholt does this apply for validating *.json files as well: https://caddyserver.com/docs/command-line#caddy-adapt?

because i am getting:

unrecognized global option: apps

with the following file:

{
	"apps": {
		"http": {
			"servers": {
				"default": {
					"listen": [
					":80"
					],
					"routes": [ {
						"handle": [ {
							"body": "hello world",
							"handler": "static_response",
							"status_code": 200
						}
						]
					}
					]
				}
			}
		}
	}
}

[francislavoie]

caddy adapt is only for Caddyfiles, caddy validate can accept both Caddyfile and JSON (and any other config format) but you need to specify which --adapter to use. unrecognized global option: apps means you tried to load your JSON config as a Caddyfile, which is incorrect.

[mholt]

To clarify, caddy adapt is for any config adapter (not just Caddyfile). You will have to use the --adapter flag for any adapter that isn't Caddyfile.

[francislavoie]

Or rather, adapt is for any non-JSON config, to turn it into JSON.