website icon indicating copy to clipboard operation
website copied to clipboard

Following the docs leads to service failure

Open ahoiroman opened this issue 1 year ago • 3 comments
trafficstars

The docs at https://caddyserver.com/docs/caddyfile/options#admin describe how to use a unix socket in order to make the api listen to the unix socket.

{
	admin unix//run/caddy-admin.sock
}

Following this leads to a service failure on restart:

Oct 01 06:07:00 server1 caddy[56725]: Error: loading initial config: loading new config: starting caddy administration endpoint: permission denied

This happens, if caddy is installed via package manager and running as user caddy.

But even if I create that socket using:

touch /run/caddy-admin.sock
chown caddy: /run/caddy-admin.sock
chmod 0600 /run/caddy-admin.sock

Leads to the very same error:

Oct 01 06:10:14 server1 caddy[56747]: Error: loading initial config: loading new config: starting caddy administration endpoint: permission denied

ahoiroman avatar Oct 01 '24 11:10 ahoiroman

As mentioned on the forum, this is due to how systemd works. Users are generally expected to know better how their system is setup and which directories should the service be allowed to access. It's not related to the file's absence/presence or the file permissions. The only thing we can do in terms of documentation is to mention that users should be mindful of their system setup and perhaps need to adjust their init system, but we cannot assume all users use systemd-led Linux distro. Other *nix systems might not have the same restrictions enforced by systemd.

mohammed90 avatar Oct 01 '24 11:10 mohammed90

My issue was in fact pointing in that direction: Adding more context to the docs.

I think I am working that out and, if it's something you'd welcome, I'll create a PR for the docs.

ahoiroman avatar Oct 01 '24 11:10 ahoiroman

PRs are always welcome and appreciated! Documentation written from user's perspective may be clearer than ones written by the developers and maintainers.

mohammed90 avatar Oct 01 '24 11:10 mohammed90

I was running into the same thing just now but wasn't sure whether to create a new bug or just comment on this. It could be fixed with the caddy package supplied unit file. (I am using Debian)

The main issue is that caddy starts as user caddy and wants to create the socket in /run which is not writable. Creating it manually is not advisable as it's a tmpfs.

Possible solution:

Add RuntimeDirectory=caddy to the [Service] section of the unit file. Change the documentation to admin unix//run/caddy/caddy-admin.sock

On unit start, systemd will create /run/caddy with the correct permissions for it to work and clean up behind it again.

kouya avatar May 02 '25 08:05 kouya

It could be fixed with the caddy package supplied unit file

We already ship unit files. Check the packaging.

wants to create the socket in /run

This is completely config dependent, so it's on the user (sysadmin) to adjust their unit files accordingly.

mohammed90 avatar May 02 '25 11:05 mohammed90

Yes, I'm using that unit file. I just meant that changing these two things in the shipped one would make the default config work out of the box. /run is never writable by arbitrary users on any system I have seen and the two changes would put it into a subdirectory while preserving all functionality.

kouya avatar May 02 '25 11:05 kouya

You can already customize your unit file, and this is documented. Not all users use unix socket for the admin endpoint, so we can't assume that nor can we assume its location.

mohammed90 avatar May 02 '25 11:05 mohammed90