Caddy - Custom configuration completely hidden from GUI Diagnostics screen

[mtchetch]

The Caddy diagnostics page does not currently show any custom configurations that might be added to the Caddyfile via the import clause.

I know that it is an edge case that people are running their own custom configurations that get imported, but I think that it is important to have visibility if this is the case.

I propose adding the imported caddyfiles into view on the diagnostics screen or at the very least have an indication that something has been imported for the user to know that not all active configuration is shown on the diagnostic screen.

[OPNsense-bot]

Thank you for creating an issue. Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.

For more information about the policies for this repository, please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

The easiest option to gain traction is to close this ticket and open a new one using one of our templates.

[Monviech]

That's why the json configuration is also exposed in the GUI, it will show the full running current configuration, transformed out of the Caddyfile and the custom imported files.

I have tested concatenation of the custom files with the caddyfile and expose that in the GUI, but that created a lot of random issues. So now, the API only reads the Caddyfile and the JSON configuration directly and exposes them to the user.

I have no plan to change this.

[mtchetch]

I understand the reasoning and accept that this will not change. Since I did not realize how important the difference between json diag and the Caddyfile was, I propose adding a note about this into the generated Caddyfile. This might be helpfull to other users.

The header could say something along the lines of:

DO NOT EDIT THIS FILE -- OPNsense auto-generated file

Running configuration including Imported custom configurations is visible in the JSON configuration tab

This change would make it hopefully more clear and does not have any impact on the codebase

[Monviech]

It doesn't have any benefit there and its not even translated.

I imply that the people or teams that use custom configuration files know the implications and keep track of them with their own documentation.

[fichtner]

I usually suggest wrapping custom files into a plugin which makes these files known to an actual entity and they can be committed to a local git repository for inspection and memory refresh :)