Skip to content

Commit

Permalink
Merge branch 'opnsense:master' into freeradius-eap-tls-multiple-ca
Browse files Browse the repository at this point in the history
  • Loading branch information
razza-guhl authored Dec 2, 2024
2 parents bc5b6e1 + 6bde751 commit b3eb2e0
Show file tree
Hide file tree
Showing 14 changed files with 291 additions and 204 deletions.

This file was deleted.

This file was deleted.

This file was deleted.

3 changes: 3 additions & 0 deletions www/caddy/pkg-descr
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,11 @@ Plugin Changelog

1.7.5

* Add: Load Balancing options to Layer 4 Proxy and HTTP Handle
* Add: Layer4 TLS Termination
* Add: h2c protocol to HTTP Handler
* Cleanup: Caddy Certificate widget hides unused automatic certificates
* Cleanup: Widgets error handling improved
* Cleanup: Refactor caddy_certs.php to Trust model

1.7.4
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -136,14 +136,6 @@
<help><![CDATA[When directive is "reverse_proxy", enter a path prefix like "/guacamole" that should be prepended to the upstream request. This is useful for destinations that have a virtual directory as their base path. When directive is "redir", add the path the request should be redirected to; leaving it empty will append {uri}.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.PassiveHealthFailDuration</id>
<label>Upstream Fail Duration</label>
<type>text</type>
<style>style_reverse_proxy</style>
<help><![CDATA[Enables a passive health check when multiple destinations in "Upstream Domain" are set. "Fail Duration" is a value that defines how long to remember a failed request. A duration of 1 or more seconds enables passive health checking; the default is empty (off). A reasonable starting point might be 30s to balance error rates with responsiveness when bringing an unhealthy upstream back online.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.HttpTlsInsecureSkipVerify</id>
<label>TLS Insecure Skip Verify</label>
Expand Down Expand Up @@ -172,4 +164,89 @@
<style>style_tls style_reverse_proxy</style>
<help><![CDATA[Enable or disable NTLM. Needed to reverse proxy an Exchange Server. Warning: NTLM has been deprecated by Microsoft. This option will stay for as long as the optional http.reverse_proxy.transport.http_ntlm module can be compiled without errors.]]></help>
</field>
<field>
<type>header</type>
<label>Load Balancing</label>
<advanced>true</advanced>
</field>
<field>
<id>handle.lb_policy</id>
<label>Load Balance Policy</label>
<type>dropdown</type>
<style>style_reverse_proxy</style>
<help><![CDATA[lb_policy is the name of the load balancing policy, along with any options. For policies that involve hashing, the highest-random-weight (HRW) algorithm is used to ensure that a client or request with the same hash key is mapped to the same upstream, even if the list of upstreams change.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.lb_retries</id>
<label>Load Balance Retries</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>off</hint>
<help><![CDATA[lb_retries is how many times to retry selecting available backends for each request if the next available host is down. If lb_try_duration is also configured, then retries may stop early if the duration is reached. In other words, the retry duration takes precedence over the retry count.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.lb_try_duration</id>
<label>Load Balance Try Duration (s)</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>0</hint>
<help><![CDATA[lb_try_duration is a duration value that defines how long to try selecting available backends for each request if the next available host is down. Clients will wait for up to this long while the load balancer tries to find an available upstream host. A reasonable starting point might be 5s since the HTTP transport's default dial timeout is 3s, so that should allow for at least one retry if the first selected upstream cannot be reached.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.lb_try_interval</id>
<label>Load Balance Try Interval (ms)</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>250</hint>
<help><![CDATA[lb_try_interval is a duration value that defines how long to wait between selecting the next host from the pool. Only relevant when a request to an upstream host fails. Be aware that setting this to 0 with a non-zero lb_try_duration can cause the CPU to spin if all backends are down and latency is very low.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.PassiveHealthFailDuration</id>
<label>Passive Health Fail Duration (s)</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>off</hint>
<help><![CDATA[fail_duration enables a passive health check when multiple destinations in "Upstream Domain" are set. It is a value that defines how long to remember a failed request. A duration of 1 or more seconds enables passive health checking. A reasonable starting point might be 30s to balance error rates with responsiveness when bringing an unhealthy upstream back online.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.PassiveHealthMaxFails</id>
<label>Passive Health Max Fails</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>1</hint>
<help><![CDATA[max_fails is the maximum number of failed requests within fail_duration that are needed before considering an upstream to be down.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.PassiveHealthUnhealthyStatus</id>
<label>Passive Health Unhealthy Status</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>off</hint>
<help><![CDATA[unhealthy_status counts a request as failed if the response comes back with one of these status codes. Can be a 3-digit status code or a status code class ending in xx, for example: 404 or 5xx.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.PassiveHealthUnhealthyLatency</id>
<label>Passive Health Unhealthy Latency (ms)</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>off</hint>
<help><![CDATA[unhealthy_latency is a duration value in ms that counts a request as failed if it takes this long to get a response.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>handle.PassiveHealthUnhealthyRequestCount</id>
<label>Passive Health Unhealthy Request Count</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>off</hint>
<help><![CDATA[unhealthy_request_count is the permissible number of simultaneous requests to a backend before marking it as down. In other words, if a particular backend is currently handling this many requests, then it is considered "overloaded" and other backends will be preferred instead. This should be a reasonably large number; configuring this means that the proxy will have a limit of unhealthy_request_count × upstreams_count total simultaneous requests, and any requests after that point will result in an error due to no upstreams being available.]]></help>
<advanced>true</advanced>
</field>
</form>
Original file line number Diff line number Diff line change
Expand Up @@ -107,18 +107,42 @@
<type>text</type>
<help><![CDATA[Choose a custom port for the upstream destination.]]></help>
</field>
<field>
<id>layer4.ProxyProtocol</id>
<label>Proxy Protocol</label>
<type>dropdown</type>
<help><![CDATA[Add the HA Proxy Protocol header. Either version 1 or 2 can be chosen. The default is off, since it is only needed when the upstream can use the Proxy Protocol header.]]></help>
<advanced>true</advanced>
</field>
<field>
<type>header</type>
<label>Load Balancing</label>
<advanced>true</advanced>
</field>
<field>
<id>layer4.lb_policy</id>
<label>Load Balance Policy</label>
<type>dropdown</type>
<style>style_reverse_proxy</style>
<help><![CDATA[lb_policy is the name of the load balancing policy, along with any options. For policies that involve hashing, the highest-random-weight (HRW) algorithm is used to ensure that a client or request with the same hash key is mapped to the same upstream, even if the list of upstreams change.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>layer4.PassiveHealthFailDuration</id>
<label>Upstream Fail Duration</label>
<label>Passive Health Fail Duration (s)</label>
<type>text</type>
<help><![CDATA[Enables a passive health check when multiple destinations in "Upstream Domain" are set. "Fail Duration" is a value that defines how long to remember a failed request. A duration of 1 or more seconds enables passive health checking; the default is empty (off). A reasonable starting point might be 30s to balance error rates with responsiveness when bringing an unhealthy upstream back online.]]></help>
<style>style_reverse_proxy</style>
<hint>off</hint>
<help><![CDATA[fail_duration enables a passive health check when multiple destinations in "Upstream Domain" are set. It is a value that defines how long to remember a failed request. A duration of 1 or more seconds enables passive health checking. A reasonable starting point might be 30s to balance error rates with responsiveness when bringing an unhealthy upstream back online.]]></help>
<advanced>true</advanced>
</field>
<field>
<id>layer4.ProxyProtocol</id>
<label>Proxy Protocol</label>
<type>dropdown</type>
<help><![CDATA[Add the HA Proxy Protocol header. Either version 1 or 2 can be chosen. The default is off, since it is only needed when the upstream can use the Proxy Protocol header.]]></help>
<id>layer4.PassiveHealthMaxFails</id>
<label>Passive Health Max Fails</label>
<type>text</type>
<style>style_reverse_proxy</style>
<hint>1</hint>
<help><![CDATA[max_fails is the maximum number of failed requests within fail_duration that are needed before considering an upstream to be down.]]></help>
<advanced>true</advanced>
</field>
<field>
Expand Down
Loading

0 comments on commit b3eb2e0

Please sign in to comment.