www/caddy Support bind directive for individual subdomains

[benniekiss]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.

In a segmented network setup, either through VLANS or multiple interfaces, an admin may not want a reverse proxy listening and redirecting traffic on all of those interfaces. In some instances, the reverse proxy may only be used to redirect internal services and provides no external WAN access. And in others, certain interfaces may only need access to certain services depending on the interface. Both the NGINX and the HAPROXY plugin support specifying a bind address for specific domains through the GUI, yet the caddy plugin does not.

The maintainer has expressed an unwillingness to add this feature because of potential issues, mainly regarding interfaces being brought up after caddy which would cause a server crash. However, this issue is not unique to caddy, as NGINX will also crash if the interface is not brought up in time.

An alternative is provided to configure the bind address via manually created *.conf files, but this requires root terminal access, which is not always available, and it adds another layer of maintenance and configuration.

Describe the solution you'd like

Allow the configuration of the bind address per domain via the GUI. This will greatly ease and reduce maintenance costs, simplify configuration, and most importantly, support segmented network security without requiring root terminal access.

I would gladly help to contribute this feature if it were to be accepted.

Describe alternatives you've considered

An admin can configure additional options via *.conf files, but this adds a layer of complexity and requires root terminal access.

Additional context

The concerns regarding dynamic IPs and slow-to-bring-up interfaces are valid, but these concerns should not limit the functionality of the plugin, and they are not reflected in the other reverse proxy plugins despite experiencing the same issue.

Putting the bind directive in the Advance Settings drop down, defaulting to listen on all interfaces, and including a warning about potential issues are all valid ways to prevent naive users from misconfiguring their setups, but this should not prevent admins from making informed decisions.

[Monviech]

https://forum.opnsense.org/index.php?topic=40993

Consider an option like that unmergable since it has too many side effects that can't be validated.

I am acting based on best practice of the more experienced core maintainers.

[fichtner]

One of the main reasons besides technical advantages and disadvantages the people using this feature correctly will mainly not be the ones giving free support to all inexperienced users stumbling over the problems related to this. It is the harsh reality for open source maintainers.

Cheers,
Franco

[benniekiss]

I understand. I do think there are good arguments for supporting this feature, and the linked discussion post seems to indicate other users want this functionality.

There was another discussion regarding nginx, and the feature was added only three years ago despite similar concerns.

Are there reports of users experiencing issues with a crashed server due to this feature? I do understand the burden placed on maintainers, but I'm interested in if this feature actually imposes that burden.

[Monviech]

Yes that feature will impose a burden.

A good example is this: https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces

After the latest update there were suddenly numerous people in the forum who complained their WebGUI was not working anymore. And they all bound to interfaces. There are also a good amount of users who just do it cause it can be selected. Even though there is a big warning popup dialog that they have to accept.

So, if you want to use this, you are free to support an own fork of this plugin where you can select it in the GUI. But I don't want the support cases for it when it breaks.

[benniekiss]

Even with the real-world issues and consequences, interface binding is still supported in the webgui and other services and plugins. My reasoning behind wanting the feature supported in caddy is that the same functionality is already embedded in more salient parts of opnsense. Listening on all interfaces and requiring root access via terminal just seems to open up security implications that, for me, outweigh the other concerns regarding potential crashes.

I respect not wanting to maintain and support a fragile feature, which this obviously would be. Thank you for taking the time to respond, and I appreciate your work!

[Monviech]

Thanks for understanding.

I'm working on fixing the root issue by the way. In the future, with the right configuration, a non-privileged user who is a member of the www group will also be able to access the caddy configuration. (Probably, its up for discussion and testing.)

#4081
#4069

[fichtner]

So, if you want to use this, you are free to support an own fork of this plugin where you can select it in the GUI. But I don't want the support cases for it when it breaks.

One thing that we usually do when possible is to allow file-based includes which could be used manually or via a secondary private plugin to manage that part (even as part of added caddy GUI feature without much separation), but I don't know how feasible this is in caddy. It's prone to breakage but both the administrative advantage and burden is on the user side.

[Monviech]

@fichtner It is already allowed since the very beginning of this plugin.

https://docs.opnsense.org/manual/how-tos/caddy.html#using-custom-configuration-files