Created attachment 214710 [details] Caddy diff 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 changes: https://caddyserver.com/v2 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.
Created attachment 214711 [details] Caddy 2 diff Updated diff, I missed the Makefile header.
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/148251505
Created attachment 214742 [details] Caddy 2 diff Updated diff, I removed the "created by" line as I needed to rewrite the Makefile. I left the maintainer as it is for now.
(In reply to Daniel Tihanyi from comment #0) Hi Daniel, For my own understanding, how important is it that Caddy V2 create a PID file, or require LOGIN and DAEMON? I haven't found these to be showstoppers in getting Caddy V2 working in the rc.d framework. This thread also seems to suggest that a PID file in not entirely necessary https://forums.freebsd.org/threads/rc-d-script-to-start-a-sh-script.63178/ I've also independently worked on an rc script. Details can be found at https://github.com/basilhendroff/freenas-iocage-caddyv2. What's reassuring is that we have got to similar points quite independently. A couple of comments on your rc script. 1. I do like elements of what you've done especially around command_args and command flags. command_args="${caddy_flags} -config ${caddy_config}" I wonder if the order should be switched though, or whether it matters? i.e. command_args="--config ${caddy_config} ${caddy_flags}" 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. Thank you for offering to maintain the port. This was raised as recently as a few hours ago by the Caddy dev in this Caddy forum post https://caddy.community/t/caddy-version-1-end-of-life-date/7835/26
A couple of questions: 1. Given the complete lack of backward compatibility, might it be better to have a separate port for Caddy v2 (called, perhaps, "caddy2")? 2. Is it possible to build Caddy's plugins with this port? I'm most interested in the DNS validation plugins, but I'd suppose any others would work the same way.
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.
(In reply to Daniel Tihanyi from comment #6) Hi Daniel, 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?'. 3. Caddy2 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.
Hi Daniel, I'd like to make a further point on the location of the Caddy binary and Caddyfile. While from a Caddy perspective, the preferred locations for V2 are /usr/bin/caddy and /etc/caddy/Caddyfile, this doesn't take into account that FreeBSD has a fairly strict filesystem hierarchy, such that (as I understand it) anything that isn't part of a base FreeBSD installation lives somewhere under /usr/local/. More information is available about this at https://www.freebsd.org/doc/handbook/dirstructure.html and man hier https://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7&manpath=freebsd-release-ports Therefore, to accommodate defaults from a Caddy V2 perspective within the FreeBSD ports framework, the transformation of those locations would likely be: /usr/bin/caddy -> /usr/local/bin/caddy /etc/caddy/Caddyfile -> /usr/local/etc/Caddyfile
Created attachment 214926 [details] caddy2-diff 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.
Created attachment 214927 [details] caddy2-diff I added now the sample configuration file which was missing before.
@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.
Created attachment 215958 [details] Caddy to Caddy2 Update 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 format 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).
Created attachment 215959 [details] Poudriere Build Log Attached Pouidriere build log
Created attachment 215979 [details] Caddy to Caddy2.1 Update And with that, Caddy 2.1 was released, I attached the updated diff. I also added the "--pidfile" option to the rc file.
Created attachment 215980 [details] Poudriere Build Log - Caddy 2.1 Also updated the Poudriere Build log.
Created attachment 216026 [details] Caddy to Caddy2.1 Update Small fix moving the --pidfile option to the start command as other commands are not accepting it as an option.
Created attachment 216186 [details] Caddy 2.1.1 Update Caddy 2.1.1 is released, the diff is attached.
Created attachment 216187 [details] Poudriere Build Log - Caddy 2.1.1 Poudriere built log is attached.
Hi Daniel, Thanks for all the effort you've put into this. Has the port or package been made public yet? I'm not seeing v2.x in FreshPorts https://www.freshports.org/search.php?stype=name&method=match&query=caddy&num=10&orderby=category&orderbyupdown=asc&search=Search&format=html&branch=head or through pkg search after executing a pkg upgrade. I've also tried compiling it using the Ports Collection by following the instructions at https://www.freebsd.org/doc/handbook/ports-using.html, but I only seem to be able to compile v1.0.4. What am I missing?
Hello Basil, in order for caddy2 to be included in ports (and be able to install it with pkg), a Ports Committer needs to accept my patch and commit it. Unfortunately this didn't happened yet. If you want to build caddy2 yourself, you can download the patch and apply it to a ports tree, then run make install. If you happen to know a committer, you can let him know about this port to speed up the process. :-)
Does the rc script support passing environment variables to caddy? It looks like this is again going to be a preferred mechanism of passing DNS validation credentials. If so, would it just be using the "caddy_extra_flags"?
Hello Dan, No, you cannot add environment variables with the rc script, but you can pass any flags with the caddy_extra_flags in rc.conf. If there is no other way, but using env. variables, you need to take care of it differently.
Hi Daniel An amendment to the etc/rc.d/caddy initialisation script appears to be necessary to address an issue that has been identified. For the details, please refer to https://caddy.community/t/how-to-use-the-expanded-form-of-php-fastcgi/9228. Your proposed caddy rc.d script was used as the basis for the caddy script located at https://github.com/danb35/freenas-iocage-nextcloud/blob/caddyv2/includes/caddy. It includes a suggested fix for the issue described as well as other refinements you may wish to consider. These are outlined below: 1. start_cmd redirects stdout and stderr to a log file (default is /var/log/caddy.log) to address the issue identifed above. It also serves to eliminate 'console spam' 2. pidfile was defined, but not used in the master copy. It is actively used in this copy. 3. required files - Enables a check for the existence of the Caddy binary and Caddyfile. This is a built-in check. With the check, a service caddy start will alert the user if either of these files is missing; without it, no cue is provided. 4. Superfluous command definitions - stop and restart, as well as many other commands such as status and extracommands, are automatically supported as defined in rc(8). See https://www.freebsd.org/cgi/man.cgi?query=rc&sektion=8&manpath=freebsd-release-ports. There doesn't appear to be any added value in including these command definitions. If anything, it makes things a little more ambiguous as it detracts from the commands that must be defined or altered i.e. start, validate and reload.
I notice that the rc script starts Caddy using the "caddy start" command, rather than "caddy run". The Caddy docs (https://caddyserver.com/docs/command-line#caddy-run) appear to fairly strongly recommend the latter command instead: "Use of (the caddy start) command is discouraged with system services or on Windows." caddy run "Runs Caddy and blocks indefinitely; i.e. "daemon" mode." Is there a reason "caddy run" shouldn't be used?
Created attachment 216939 [details] Caddy 2.1.1 Update @Basil: Thank you very much for the info, I copied the rc script you linked and I'm already running Caddy with it since a couple of days. It's running fine, so I updated the port with it. I hope this bug will be noticed soon so it can be included in the ports tree.
@Dan: I tried caddy run as well, but if I use that, even with the service command, I won't get back the promt. It can be mitigated by using the daemon command, but so far "caddy run" works fine, so I don't see the point why not to use it.
maintainer timeout (the original patch did not receive feedback for over two months now)
testbuilds are fine
A commit references this bug: Author: pi Date: Thu Aug 6 17:35:43 UTC 2020 New revision: 544283 URL: https://svnweb.freebsd.org/changeset/ports/544283 Log: www/caddy: upgrade 1.0.4 -> 2.1.1 - previous version was deprecated by upstream - submitter becomes maintainer PR: 246623 Submitted by: daniel.tihanyi@tetragir.com Reviewed by: basil.hendroff@gmail.com, dan@familybrown.org Approved by: fabian.freyer@physik.tu-berlin.de (maintainer timeout) Relnotes: https://caddyserver.com/v2 Changes: head/www/caddy/Makefile head/www/caddy/distinfo head/www/caddy/files/Caddyfile.sample.in head/www/caddy/files/caddy.in head/www/caddy/files/extra-patch-disable-telemetry head/www/caddy/files/pkg-message.in head/www/caddy/pkg-descr
Committed, thanks!
In case archivers/zstd is installed, the build breaks due to obsolete Golang wrapper around libzstd. Updating the wrapper to latest version fixes the problem. The patch is at bug #248547.