I use a Caddyfile with multiple domains and every time I add or modify a sites configuration I have to restart and wait for the SSL to be configured. Can it be done without a restart of Caddy?
Also if something is wrong with the configuration Caddy never really starts and just throws a fatal error. Is it possible to start with all sites that did not have a configuration error?
From my experience, what is typically happening here is that an error that looks trivial to the eye causes the parsing of the rest of the CaddyFile to go awry. So once an error has been discovered, none of the sites that are defined past that point (which could also include further parts of sites already parsed) can be relied on. Therefore a fatal error is the only safe option.
Understandable if it is a typo. But if the error is that a domain is not pointing to the server and the ssl certificate can not be generated then a soft fail would be nice.
Yes, and I strongly recommend this: use signal USR1 to have Caddy reload the configuration with 0 downtime. It will roll back the configuration if there is an error: https://caddyserver.com/docs/cli#signals
No – fix the configuration error. 
We’ve learned from experience that this is a good way to go. I realize this is different from other web servers but, after all, the point of Caddy is to be different. (In a better way, ha.)
The current behaviour is actually good. Starting partially could give the impression that everything is fine and you’d be looking for errors in the wrong place.
Thanks, signals is what I needed. Will try that!
and how does one do this? particularly in windows?
The Windows Subsystem for Linux implements a number of POSIX standards, including kill signals, I understand.
Outside of that, unfortunately, Windows is not capable of issuing different types of kill signals to running programs. So, while I suppose this graceful reload functionality technically exists in Windows builds of Caddy, the base OS offers no way to trigger it.
would it be possible to build a second exe that just kinda sends soemthing to the caddy software? although I dont know how much it is possible to have different softwares interact directly in windows, especially without admin privileges.
if there would be a GUI there might be a way to go from parent to child but on the same level, especially for a backgound CLI it might be harder.
Good question. At the bare minimum, Caddy happens to be fluent in HTTP (heh), so I could imagine that a directive to listen on a specific host/port/location and trigger a reload when it receives a request is probably in the realm of possibility.
I think most of the contributors run Caddy on Linux exclusively, so I’m sure some ideas on how to tackle this in Windows would be quite welcome.
well at least I run caddy on windows for dev especially because I can swap the PHP versions quickly by just closing one fCGI window and opening another.
although I have to admit that because I wanna use it at work (and I probably wont get my boss to pay) I just went and got myself the Go compiler (although I also use it at home and i really like it (except for a few smaller things like the lack of output control (see the topic I wrote in december) and htaccess style directives)
but yeah HTTP sounds pretty good, a l-host-only with a specific port would be a way obviously, otherwise one could also implement a password-based solution with HTTP basic auth.
I would support this idea - a specific port, that is, rather than authentication through a main site. A very simple page could prompt for which signal is to be sent.
a specific port is a way, but it obviously has the issue that just having a page with “which signal do we send”, we would immediately have the problem that these can be immediately be shown with a portscan, unless caddy finds a very pecific way to play dead until a very specific URL or whatever is being tried to call, a thing which you cant do on HTTPS as you first would have to exchange certificates. a custom hidden URL somewhere behind the site, so basically hidden in plain sight, wouldnt be a too bad Idea.
IF there would be a way to allow communication from PHP to caddy (without exec, obviously), one could even turn this up to eleven and have a “signal caddy” subsite, in the administrative panel of the site, for example.
Well, I mean, if we are talking HTTP(S) here, authorization is a solved problem. Use HTTPS and set some known header to some secret value. Maybe even set the endpoint to some crazy 64-random-character URI (as you say a “custom” hidden URL). Only listen on a specific port on a specific interface. Lots of potential there to secure things.
PHP can talk to Caddy easily with web requests.
As for “which signal do we send”, as signals mean nothing in a Windows context, it’s more about picking which functionality. In my mind, you’d select which function the endpoint triggers when you configure it in the Caddyfile. The only functions which are missing are graceful shutdown, configuration reload, and binary reload. I don’t think binary reload is going to be possible in Windows due to how file handles work, so only two functions. Think something like this (all values are examples only):
https://192.168.150.50:26156 {
tls self_signed
trigger reload /d78901c2da689315fd96b9f73138132c {
expect_header X-Reload-Auth 581e08bf31071b4985c323af938eff3a
whitelist 192.168.0.0/16
}
}
That kicks off a Caddyfile graceful reload when you execute curl -k https://192.168.150.50:26156/d78901c2da689315fd96b9f73138132c -H "X-Reload-Auth:581e08bf31071b4985c323af938eff3a" from the local network.
although to be honest I am not really a fan of using headers for everything, one reason of it simply not being able for use in the browser, which if you for example need to run a quick restart or shutdown of caddy on the go (if needed for some reason) it’s kinda sad when one cannot do it because one cant just do it in the browser, aka something that basically works everywhere.
but generally speaking the Idea isnt bad.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.