Messages

hi
try to use opnsense_stream_vhost_plugins folder for the file with your custom config
https://github.com/opnsense/plugins/blob/3c5e2b9d771bf8e7145eb659f1d8a4302640cc62/www/nginx/src/opnsense/service/templates/OPNsense/Nginx/http.conf#L69C1-L69C18

try to use hooks
https://forum.opnsense.org/index.php?topic=27050.msg131201#msg131201

Hi
Have you tried to exclude 'okhttp' from Bots User Agents at Global HTTP Settings?

Hi
the specified resolver can be used not only by ssl_stapling, so I wanted to leave the possibility of more fine-tuning than specifying it at the global level. (there is a http_post/*.conf hook at the global level. Advanced users can define a global parameter with it).

Maybe it would be a good idea to set the resolver to "127.0.0.1, [::1]" for a HTTP Server if "None" is selected to mitigate the unnescessary warnings in the log.
my logic is - if the message bothers, the user can configure the resolver. if not - user can always filter the logs and not show messages below the error level. I don't think it's the best idea to substitute the resolver value without the user's knowledge  ;)

Hi!
sorry, have you assigned this resolver to the server with this LE cert?

Hi.
It is necessary to create WAF rule(s), combine them into WAF policie(s) and assign policies to Location(s).
Has this been done?

https://github.com/opnsense/plugins/pull/4092

@franco
thanks again!

@ealbright
there is no "disable handshake logging" checkbox yet in 1.33 (a little busy and didn't have time, sorry)
i will try to add it and make a pr asap (I hope it's a quick-fix)

"Enable Let's Encrypt Plugin Support" enabled at Server settings and then a configured location added also?

Hi
https://github.com/opnsense/plugins/issues/3854

Hi.
-These headers are intended to show the client where the original server/proxy resides in a heterogeneous systems
I still don't understand why you think using an XFF header in the '<arbitrary_external_server_address>, $proxy_add_x_forwarded_for' format satisfies the standard way if it assumes the '<client>, <proxy1>, <proxy2>' format.
if there was no NAT in front of the nginx, the external address of the plugin would also not be included in this header

-No, I can't. You are talking about some abstract suggestion..
It would be more accurate to say not a non-standard header, but non-standard requirements?

-Does it survive the update/upgrade of OPNsense? I mean -- is this a standard way for OPNsense?
This is certainly not the preferred method (preferably all settings are available in the UI) but it is included in the plugin templates. and yes, it will survive the reboot\update\upgrade.

I'm not a plugin maintainer, so feel free to ignore my assumptions  :) I just believe that changes requests should be motivated and I understand that I would not come up with enough justification for the maintainer to accept my arguments in this case

Hi
i think the quickest way to do this with the $SERVICE monit variable:
change "Service name" to something like "My_server_check" and
change Telegram message template ('Message' field with 'Advanced mode' enabled in Telegram settings) to something like:

Code Select Expand


<b>DATE:</b> {MONIT_DATE}
<b>HOST:</b> {MONIT_HOST}
<b>SERVICE:</b> {MONIT_SERVICE}
<b>DESCRIPTION:</b>
<pre>{MONIT_DESCRIPTION}</pre>

to include this variable to message

Hi
I'm not sure that I fully understand, but if you want to do this through GUI, you will have to make two servers:
x1.domain.io
x2.domain.io
(upstream may be left alone)
To add a folder to URL, you can add two rewrite rules like:
rewrite ^(/zs/ef/x/)(.*) $1x1/$2 last;
rewrite ^(/zs/ef/x/)(.*) $1x2/$2 last;

and add them to the appropriate servers.
but I'm really not sure I understood the intent correctly

https://github.com/opnsense/plugins/pull/3678 ?

yep, backend server should treat ip from XFF as a client IP )
settings depend on the server