Wekan Open Source kanban https://wekan.github.io Snap version https://snapcraft.io includes Caddy v1.
Today when building Wekan Snap, that Canonical’s Snap do by downloading Wekan source code from GitHub - wekan/wekan: The Open Source kanban (built with Meteor). Keep variable/table/field names camelCase. For translations, only add Pull Request changes to wekan/i18n/en.i18n.json , other translations are done at https://transifex.com/wekan/wekan only. etc dependenices, build servers stopped to error that Caddy v1 download URL did not work anymore. I do still have that binary in current Snap.
But, Wekan Snap is currently deployed to about 8000 servers all around the world that each have some default or customized Caddyfile v1. I do not have direct access to those servers to edit each of about 8000 config files manually.
Is there Caddyfile v1 adapter? Or how could I migrate all at once?
Maintainer of Wekan
I’m afraid not. There are fundamental handling differences that make dictionary style translation effectively impossible for a huge number of use cases. It would be inadvisable to attempt a mass conversion.
You can still use Github to download the release, or alternatively, have the build servers build Caddy as part of the process. Effectively only the custom Caddy v1 build servers supplied by caddyserver.com are retired.
one thing you can do, is possibly make a release informing your userbase of the upgrade to v2, and to tell them that if they have customized configs to start working on porting their configs to v2.
If the user has the default configs they dont have to worry, as they would be automatically updated.
Either way, the task would be much easier if there was a tool to port a v1 config to v2, even if it was a bunch of sed commands.
Well, “effectively impossible” is actually the same as “submit pull request” because Caddy v2 also has config adapters for Nginx etc.
Those adapters make a lot of inferences. They’re great for starting points, but typically some manual touch-up would be required. I assumed this would not be feasible for you, since you mentioned there are around 8000 config files.
My concern is that you will not get a reliable, comprehensive, dictionary style translation (i.e. 1 to 1 behaviour) for a large number of v1 → v2 Caddyfile upgrades without some serious heuristics. Caddy v1 and Caddy v2 are just different under the hood, they don’t operate quite the same. Simple translations won’t be bulletproof.
When I said impossible, I hedged my bets by saying effectively. I’m sure it can be done, but the library that does the translating would have to be so comprehensive as to be prohibitively complex. To me, that puts it outside the realm of “the same as “submit pull request””.
But I think a lot of people would be very happy if I were wrong about that - including me - so if any reader has some ideas, please, give it a shot! Writing a config adapter is technically straightforward.
This topic was automatically closed after 30 days. New replies are no longer allowed.