-
Notifications
You must be signed in to change notification settings - Fork 603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
www/caddy: include os-caddy into OPNsense plugins #3840
Conversation
Changed How to install to refer to OPNsense plugins.
Hi, the vendor space is for partnership purposes to add third party repositories only. The directory structure is also just 2 directories deep to be compatible with FreeBSD ports. i think caddy should live under www/caddy to align with the FreeBSD port also. Cheers, |
Thanks for the explanation I will change the path. |
Remove stray copyright
Removed reference to external documentation
Change dependency to caddy-custom to align with binary name in opnsense repo.
….d caddy script that's provided by the caddy-custom.pkg. It hooks into the onestart/onestop/onerestart actions and executes the custom setup.sh script of caddy whenever the opncaddy service is started. Additionally, all references of caddy in the service files, action files have been replaced with this opncaddy wrapper script. Due to this change, the current caddy rc.d script from the caddy-custom can be used unaltered while calling it from the opncaddy wrapper script.
…sting rc.d caddy script that's provided by the caddy-custom.pkg. It hooks into the onestart/onestop/onerestart actions and executes the custom setup.sh script of caddy whenever the opncaddy service is started. Additionally, all references of caddy in the service files, action files have been replaced with this opncaddy wrapper script. Due to this change, the current caddy rc.d script from the caddy-custom can be used unaltered while calling it from the opncaddy wrapper script." This reverts commit 70b963a.
…e location in plugin.inc since the path changed when using the standard rc.d service script.
…e location in plugin.inc since the path changed when using the standard rc.d service script. Removed custom rc.d service script.
www/caddy/src/opnsense/service/conf/actions.d/actions_caddy.conf
Outdated
Show resolved
Hide resolved
www/caddy/src/opnsense/service/conf/actions.d/actions_caddy.conf
Outdated
Show resolved
Hide resolved
www/caddy/src/opnsense/service/conf/actions.d/actions_caddy.conf
Outdated
Show resolved
Hide resolved
www/caddy/src/opnsense/mvc/app/controllers/Pischem/Caddy/Api/ServiceController.php
Outdated
Show resolved
Hide resolved
Fix Typo in description
Change Namespace and Model mount from Pischem to OPNsense. No migration path will be offered since its too much effort to write a migration script for this.
@AdSchellevis @fichtner I have changed the Namespace and Model mount completely to OPNsense. I won't write a migration script for this. I have tested it and things seem to work as expected. Since there were a lot of changes now, it would be good if somebody else could build the package from this and test it too. |
@Monviech best keep the |
Why will the data be lost, its still there, just under a different namespace in the config.xml. When this version is installed, a new caddy under the OPNsense namespace will appear, without any data. But the caddy in the Pischem namespace will still have all the old data. If not everything is changed now, its not in line with all the other plugins and it will be always weird later. |
The data itself won't go, you just can't access it anymore with your plugin :) (and your template likely won't try to read it when re-generating as these should point to the new location as well). My suggestion was only to ease the transition, moving the config namespace with a migration can be done later as well. I prefer the OPNsense namespace, but for the model I'm ok with leaving it as is in a first version. You can choose your strategy, I'm merely trying to make sure you have all data to choose wisely ;) |
@AdShellevis if the goal is that all data has to be retained, then I will sit down and write a Migration script for it. Rather now than later when the impact would be greater. Having the framework right in the beginning should be the better choice? |
Usually divide and conquer is the better approach. The scope of this PR was to bring it in so no need to overcommit on the goal. I’d also vote to leave the data mounted where it is now and deal with the next phase after a bit of stabilization in 24.1.4/5. |
@fichtner Okay I will revert these last commits tomorrow and make sure the current model stays mounted. |
…lates, migration scripts, model mount, plugin.inc, configuration sections. Everything that interacts with model and the namespace uses OPNsense\Caddy.
@AdSchellevis @fichtner Okay I think the latest commit does the trick. Everything configuration related interacts with the old config section, and everything else with the OPNsense\Caddy namespace. I would like to freeze changes here for now and want to continue from a new good known state once this has been merged. Thanks for the feedback on how to tackle this. |
Use integrated php 8.0 function str_ends_with() instead of the haystack helper function.
removed '$this->' because 'str_ends_with()' is not a method of the 'Caddy' class, but a global PHP function.
I have pushed a plugin revision 1 in my other repository due to a hotfix, that's why OPNsense will have the revision 2 so it will be preferred in the future.
@@ -0,0 +1,205 @@ | |||
# Caddy Plugin for OPNsense |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just as a side node this fits rather well for a page in the docs repo instead of dangling here in the repo but it's not a problem. just something for the wishlist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes my plan is to write a doc page too eventually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ready for merge? it's magic friday! ;)
merged, thanks! |
👍 to all... |
Refer to issue: #3838
I thought about a way to provide this as easily as possible as pull request, my eyes fell on the "vendor" folder.
Since I have made an own Namespace as stated in the documentation, it looked like the right place for the source code under my vendor name. Refer to: https://docs.opnsense.org/development/examples/helloworld.html#model "You should name this location with your vendor and module name..."
Thank you. ^^