caddy 2.0.0 has been released and it obsoleted caddy 1.x.
There is no official list of changes, they created a site highlighting the
The official rc script from version 1.x is gone, I wrote a new one using
caddy's own commands. At this time caddy 2.0 cannot create a pid file, however
it will be implemented in 2.1 (https://github.com/caddyserver/caddy/issues/3235 ). I will update the rc as well once 2.1 is released to install the pid file.
I am also willing to take over maintainership for this port.
Why? For instance, it may facilitate implementing a 'quiet mode'. As you will
be aware, the Caddy start and reload commands generate quite a lot of output.
In its simplest form, this can be prevented by setting caddy_flags="> /dev/null
2>&1" in /etc/rc.conf.
2. The script I came up with is very similar to yours, but deviates slightly in
a couple of places. You might like to consider these deviations.
2.1 Kudos on the start, validate and reloads methods. However, it's not exactly
clear to me why you've implemented a separate stop method. The built-in method
appears to work well.
2.2 The location of the Caddyfile and Caddy executable, I've set up as
configurable script parameters caddy_config_path and cadd_bin_path. For
instance, I think in the V1 rc script, the default Caddyfile location was
/usr/local/www/Caddyfile. This may be important for some users migrating from
V1 to V2.
--- Comment #6 from Daniel Tihanyi <[hidden email]> ---
Thank you for the feedback!
@Basil: As far as I've read here:
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/rc-scripting/article.html pid file creation is desired, but I don't think it's absolutely necessary. I
just left out the workarounds with install or daemon because I also think that
it's not absolutely necessary for a service to run, but it's nice. I will
modify the rc script once 2.1 is released.
Also from the same document it's nice to wait until LOGIN. NETWORKING also
sounds logical. Regarding daemon, I'm not entirely sure if it is needed there,
I was loooking at the rc.d script of www/h2o and it was listed there.
Sure I guess reordering makes sense. I've created a stop method because it has
one, I'm not sure which one is "better". I tough maybe there is something extra
that caddy's own stop procedure does.
@Dan: I guess we can create a separate www/caddy2 port. I'm not sure if
anything is needed from my site, I am happy to add the svn diff against and
empty caddy2 port. Regarding plugins, I'm not sure how can you do that without
using xcaddy. I'm open to see suggestions how the Makefule should look live to
use xcaddy and also maybe some Options to build it with DNS or other plugins.
--- Comment #7 from Basil Hendroff <[hidden email]> ---
(In reply to Daniel Tihanyi from comment #6)
Thank you for considering the additional feedback from Dan and myself. I would
also encourage you to visit and continue to monitor the Caddy forum post
https://caddy.community/t/caddy-version-1-end-of-life-date/7835/11 as there has
been some new feedback from the Caddy team, and, it is likely the
Caddy team will use this as the vehicle for further feedback.
There are two key stakeholder groups here - Representing and driving it from
the FreeBSD side, at this stage, are you, Dan and me; From the Caddy side, it
is Matt Holt and his team. Where possible, we want to try and accommodate the
interests of both groups. I'm going to try to impartially, but critically,
speak to this in the points below.
1. pidfile, DAEMON, etc.
Like you, I'm scratching my head wondering about the significance of some
elements. Maybe there's a gap in my knowledge; maybe it's a FreeBSD compliance
thing. If it's the latter, what bothers me is that we add in superfluous
elements that appear to add no real value to running Caddy in the FreeBSD rd.c
framework. The issue that we create is that, down the track, those following in
our footsteps, lose sight of what's relevant and what's not.
Thank you for considering my suggestion about command_args reordering. I still
think this is a good idea, however, based on feedback from the Caddy team, I
now withdraw my comments about a 'quiet mode'.
2. The location of the Caddy binary and Caddyfile.
From a FreeBSD perspective, if you are to maintain backward compatibility with
the V1 package, the Caddy binary should be located in /usr/local/bin/caddy and
for the Caddyfile it is /usr/local/www/Caddyfile. From a Caddy perspective, the
preferred locations for V2 are /usr/bin/caddy and /etc/caddy/Caddyfile.
The way to accommodate both groups is to include configurable script parameters
in the rc script for both the binary and Caddyfile. The tough decision for you
to make will be to decide which set of defaults to use. I think the question
for you to consider in this will be 'Which stakeholder group will benefit most
from the defaults?'.
I can understand why Dan has raised this. Matt has some concerns with the
approach though. I think what's important from a FreeBSD perspective is that
both V1 and V2 continue to be available for the foreseeable future. Given the
lack of backward compatibility, this is not an unreasonable request. Is it
possible to accommodate both Dan and Matt's concerns? I don't have enough
understanding of the ports framework to make any suggestions around this, but I
guess, ideally, caddy should default to the latest version, but V1 should be
selectable via some switch.
I updated the port, now we install a sample configuration file to
/usr/local/etc/caddy/Caddyfile.sample. I also updated the description, added an
install message and reordered the rc script to make caddy_options the argument.
I also corrected couple of errors I found in the Makefile and rc script.
portlint now says it"s fine, also passes poudriere tests.
--- Comment #11 from Daniel Tihanyi <[hidden email]> ---
@Basil: with this Makefile, caddy will install to /usr/local/bin/caddy. This is
the standard location on FreeBSD. I'm also creating a sample Caddyfile in
/usr/local/etc/caddy/Caddyfile, but the user is free to put the config anywhere
and point the rc script also there.
I've completely rewrote the rc file, now it works fine (I already run it in
production). It's much shorter and easier then before. Also
- Instead of caddy_flags, the user has to pass arguments to caddy_extra_flags.
This is to avoid to usage of using command_args.
- Extra commands now contains restart as previously "service caddy restart"
couldn't actually restart the process.
- Added caddy_adapter variable in case the configuration is not in caddyfile
Besides this, I experimented with DNS plugins. I had a working state where all
DNS plugins would be compiled in, but it drastically made the package bigger so
I opted not to include all. I'm experimenting still to have a config option
where the user can chose 1 from the possible DNS plugins. I'm not sure when
will I have time to finish it.
I also edited the title to have caddy2 as a new port instead of just updating
caddy. This is because the configuration of caddy1 is not compatible with
caddy2. I also updated the maintainer to myself for the new port.
I tried a couple of methods to correctly include the version into the build,
but it doesn't seem to work so "caddy version" will still report (devel).