I recently move to v2. With the cloudfalre module. But I cannot find the related files now.
I checked the answer on Github, Forum, and StackOverflow.
I have tried the ~/.caddy and ~/.local/share/caddy.
From jornal log:
Aug 17 14:26:19 localhost.localdomain caddy[1714]: {"level":"info","ts":1597688779.2268736,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["domain.com"]}
Here’s the storage docs:
I didn’t find the files under $XDG_DATA_HOME/caddy or $HOME/.local/share/caddy.
I compile caddy v2 with
xcaddy build master --with github.com/caddy-dns/cloudflare@latest
Instead, I just found the files just under /var/lib/caddy/.local/share/caddy/ which is not indicated in Conventions — Caddy Documentation.
It is very wired, can u explain it?
That’s because $HOME is the home directory of whatever user Caddy runs under. If you’ve installed Caddy with apt for example, then Caddy runs under the caddy user, as defined by the systemd service file, which has /var/lib/caddy as its home.
You didn’t fill out the thread template, so I’m forced to make assumptions about how you’re running Caddy. Next time, please fill out the template so we’re not in the dark.
Well, I think that should be updated on the Conventions — Caddy Documentation. Otherwise, normal users will no be noticed to see the caddy.service file. I see too many issues on github or other platforms to ask similar questions. The document is bad.
This isn’t bad. Our documentation describes how Caddy works, not how your computer works. Our documentation simply cannot describe how everyone’s computers work. You’ll have to know how your computer works first in order to run a web server.
To help make things easier, Caddy’s default service file runs Caddy with the --environ flag, which prints the relevant environment information to the logs for you. Among the information at the very beginning is:
caddy.HomeDir=/Users/matt
caddy.AppDataDir=/Users/matt/Library/Application Support/Caddy
caddy.AppConfigDir=/Users/matt/Library/Application Support/Caddy
caddy.ConfigAutosavePath=/Users/matt/Library/Application Support/Caddy/autosave.json
caddy.Version=(devel)
.
.
.
USER=matt
HOME=/Users/matt
.
.
.
So you can always look in the logs if you aren’t sure.
Well, can u explain why adding User and Group on the service file when publishing the deb package via apt. In this case, you should already know it will misleading users who is new to caddy. BTW, the nignx service file doesn’t contain it.
Because that’s how linux works. You isolate programs to their own users so they don’t have access to things they shouldn’t have access to. It’s the basics of *nix security.
This isn’t something isolated to Caddy. If you install nginx or apache, they will install a service which runs it under a different user. Those servers don’t manage your certificates for you though, and they use different conventions for config locations.
Nginx runs the parent process under root, but then forks another process and runs it as www-data (i.e. the default user set in the nginx.conf). Caddy avoids running as root altogether, giving you better security (for example if a vulnerability is found in Caddy, then someone wouldn’t be able to escalate the vulnerability to take over your whole system).
Caddy is architecturally very different to other servers, so ultimately, comparing them is like comparing apples and oranges in most cases.
Now, you finally answer the first question. Since you did use User caddy to run the service to protect the system on purpose. Why not mention that on documents that, for almost *nix system, the location for store cert and key file will be on caddy_home. Instead of misleading users to find nothing on Conventions — Caddy Documentation and ask duplicated questions.