OPNSense/core ff91932 — src/etc/inc/plugins.inc.d dpinger.inc, src/opnsense/mvc/app/controllers/OPNsense/Routing/forms dialogEditGateway.xml
System: Gateways: Configuration - add "Kill states when down" option trigginer a gateway kill for all states with this gateway set, proposal for https://github.com/opnsense/core/issues/6803
* hide monitor options when disabled
* wire configd kill gateway command for 'pfctl -k gateway -k gwip'
* pass required properties in dpinger_status()
system: dial this back, right intention wrong reason #8199
(cherry picked from commit 45be6d398143b487eae369480a1a3a7f745ca123)
system: change the "monitor" syshook and de-deprecate; closes #8199
(cherry picked from commit af235daa4383657eb015e799fd8d927090809779)
(cherry picked from commit e28aa1ab0199b70478e2ae224b3c0d7ca513297f)
OPNSense/core a554d13 — src/etc/inc/plugins.inc.d/openvpn wizard.inc, src/opnsense/mvc/app/views/OPNsense/Diagnostics health.volt
Merge branch 'master' into interface-bootgrid-partial
system: dial this back, right intention wrong reason #8199
OPNSense/core e28aa1a — src/etc/rc.syshook.d/monitor 20-recover, src/opnsense/scripts/routes gateway_watcher.php
system: oversighs in #8199
system: change the "monitor" syshook and de-deprecate; closese #8199
We move the gateway recovery into the hook as a user and users
can do their on similar scripts to fetch current status and
inspect and react accordingly. We do so before filter reload
to avoid excessive reloads in the facility script(s).
What this loses is the ability to get the previous argments
for statistics, but OTOH it also reduces the risk for spurious
events as we only trigger on state transitions.
OPNSense/core c2bcb3f — src/etc/inc/plugins.inc.d wireguard.inc, src/opnsense/mvc/app/controllers/OPNsense/Diagnostics/Api SystemhealthController.php
Merge remote-tracking branch 'origin/master' into gateways
system: keep polling if watcher cannot load a class
(cherry picked from commit 16ce982fa6a2de8af1eeceec0ba69424370ba442)
(cherry picked from commit edeff46f3fbfd6b067c65a66176db37e5b13c717)
system: ok it's an Error then
system: keep polling if watcher cannot load a class
This happened two times now...
[09-Oct-2023 19:25:44 Europe/Berlin] PHP Fatal error: Uncaught Error: Class "OPNsense\Base\ModelException" not found in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php:314
Stack trace:
thrown in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php on line 314
OPNSense/core 3655218 — src/opnsense/mvc/app/models/OPNsense/Proxy Proxy.xml, src/opnsense/mvc/app/models/OPNsense/Unbound Unbound.xml
Merge branch 'master' into gateways
note: this commit also accomodates the changes made in
https://github.com/opnsense/core/commit/3786caf568a34083f6cefcb521caa45d321c57a0
OPNSense/core ac0499f — src/opnsense/scripts/OPNsense/Monit gateway_alert, src/opnsense/scripts/routes gateway_watcher.php gateway_status.php
system: avoid plugin system for native dpinger scripts fetching dpinger_status() #6825
(cherry picked from commit a2ab96833d9764e34384120d9fa597336da88c77)
(cherry picked from commit 31593b1e6fa71631ebce2cd2cda41ef0b4656c66)
system: small refactor for clarity
OPNSense/core a2ab968 — src/opnsense/scripts/OPNsense/Monit gateway_alert, src/opnsense/scripts/routes gateway_status.php gateway_watcher.php
system: avoid plugin system for native dpinger scripts fetching dpinger_status() #6825
system: handle force_down correctly in gateway watcher
It was raised on the forum that this is not seen and was likely ignored
by the old system in the past as well.
(cherry picked from commit 7f1d8c66d3a5c0f8ee34c82b7319e76ea5c0ebc4)
system: defer config reload to SIGHUP in gateway watcher
This should considerably lower CPU usage as reported a few times.
We do need to bring in pcntl PHP module in order to get that done
easily in the script.
PR: https://forum.opnsense.org/index.php?topic=35219.0
(cherry picked from commit b94097567cbb116025f54772609eef7b9a8e3f4e)
(cherry picked from commit 587a50cb7c8c04af71f36ccc74a1464383916607)
system: defer config reload to SIGHUP in gateway watcher
This should considerably lower CPU usage as reported a few times.
We do need to bring in pcntl PHP module in order to get that done
easily in the script.
PR: https://forum.opnsense.org/index.php?topic=35219.0
system: handle force_down correctly in gateway watcher
It was raised on the forum that this is not seen and was likely ignored
by the old system in the past as well.
OPNSense/core 1f161de — src/etc/inc/plugins.inc.d dpinger.inc, src/opnsense/scripts/routes gateway_status.php gateway_watcher.php
system: improve monitoring of down gateways #6728
(cherry picked from commit 15d993af50197f2ef6cc83636d286cc461e8275c)
(cherry picked from commit 26ddbd1e752a7e9666774a96e9898ffb6a891d2c)
(cherry picked from commit cf61c3d1e9ae789385c2bc6277905392f880eedf)
(cherry picked from commit 8967be64c5b698b17adc4958dd98ebb0c99003ab)
(cherry picked from commit 1e74ff3b3d5bc601df0cc0d365fb23081b15542b)
(cherry picked from commit 457f6bedf51d7c081d1e4812ce1b9ccc48befb9f)
(cherry picked from commit 4ecbd9240dd74c29e6b5f39228ffff946084db0f)
(cherry picked from commit 3844bc5014f6bb4d1035483a30834ed73f9f7e44)
(cherry picked from commit 77ac3f5c938e3000e92161fe48e737cf88a424c3)
(cherry picked from commit 93f8b70cbdbe1f42c856cd979ebfa9fffe26f14b)
(cherry picked from commit a7c1facc0926ce15b9c045e0bb0f3b0f94cfca12)
OPNSense/core d1d255a — src/etc/inc/plugins.inc.d dpinger.inc, src/opnsense/scripts/routes gateway_status.php gateway_watcher.php
system: improve monitoring of down gateways #6728
(cherry picked from commit 15d993af50197f2ef6cc83636d286cc461e8275c)
(cherry picked from commit 26ddbd1e752a7e9666774a96e9898ffb6a891d2c)
(cherry picked from commit cf61c3d1e9ae789385c2bc6277905392f880eedf)
(cherry picked from commit 8967be64c5b698b17adc4958dd98ebb0c99003ab)
(cherry picked from commit 1e74ff3b3d5bc601df0cc0d365fb23081b15542b)
(cherry picked from commit 457f6bedf51d7c081d1e4812ce1b9ccc48befb9f)
(cherry picked from commit 4ecbd9240dd74c29e6b5f39228ffff946084db0f)
(cherry picked from commit 3844bc5014f6bb4d1035483a30834ed73f9f7e44)
(cherry picked from commit 77ac3f5c938e3000e92161fe48e737cf88a424c3)
(cherry picked from commit 93f8b70cbdbe1f42c856cd979ebfa9fffe26f14b)
system: assume first status as 'down' to get initial alert #6728
In some scenarios this is needed to recover the system correctly,
e.g. when the default gateway selected during boot is not actually
plugged in.
OPNSense/core f696930 — src/etc/rc.syshook.d/monitor 10-dpinger, src/opnsense/scripts/routes gateway_watcher.php
system: fix and adjust a couple of things for #6231
Do not "leak" state transitions and also always log them to the
gateway log if they aren't being pushed through the rc.syshook
alarm path. While here consolidate the logging into the script
and make 10-dpinger script a stub for the "monitor" facility.
system: move gateway monitor trigger to separate script #6231
1. The process runs forever to retain proper state, periodically
syncing the configuration data in order to react correctly.
2. Missing gateways are not an issue. They will not alert or stick
to their last verified value.
3. We stop reacting unless a default gatway switch action will follow
or the gateway is part of a gateway group. Triggers are not refined
for now so we just let it run in full processing if a candidate.
4. Emulate the strange monitor alarm output although I don't see the
use for all of this cryptic goo. The alarm state (0, 1) was changed
to reflect the observed transition causing the alarm script to run.
5. Move the action for the script alarm to the script itself. Requires
a bit of backend shuffling as well.
6. Only create one script to watch all monitors. Easier to manage and
to present as service (which can be stopped and started if needed).
system: move gateway monitor trigger to separate script #6231
1. The process runs forever to retain proper state, periodically
syncing the configuration data in order to react correctly.
2. Missing gateways are not an issue. They will not alert or stick
to their last verified value.
3. We stop reacting unless a default gatway switch action will follow
or the gateway is part of a gateway group. Triggers are not refined
for now so we just let it run in full processing if a candidate.
4. Emulate the strange monitor alarm output although I don't see the
use for all of this cryptic goo. The alarm state (0, 1) was changed
to reflect the observed transition causing the alarm script to run.
5. Move the action for the script alarm to the script itself. Requires
a bit of backend shuffling as well.
6. Only create one script to watch all monitors. Easier to manage and
to present as service (which can be stopped and started if needed).
system: move gateway monitor trigger to separate script #6231
1. The process runs forever to retain proper state, periodically
syncing the configuration data in order to react correctly.
2. Missing gateways are not an issue. They will not alert or stick
to their last verified value.
3. We stop reacting unless a default gatway switch action will follow
or the gateway is part of a gateway group. Triggers are not refined
for now so we just let it run in full processing if a candidate.
4. Emulate the strange monitor alarm output although I don't see the
use for all of this cryptic goo. The alarm state (0, 1) was changed
to reflect the observed transition causing the alarm script to run.
5. Move the action for the script alarm to the script itself. Requires
a bit of backend shuffling as well.
6. Only create one script to watch all monitors. Easier to manage and
to present as service (which can be stopped and started if needed).
system: move gateway monitor trigger to separate script #6231
1. The process runs forever to retain proper state, periodically
syncing the configuration data in order to react correctly.
2. Missing gateways are not an issue. They will not alert or stick
to their last verified value.
3. We stop reacting unless a default gatway switch action will follow
or the gateway is part of a gateway group. Triggers are not refined
for now so we just let it run in full processing if a candidate.
4. Emulate the strange monitor alarm output although I don't see the
use for all of this cryptic goo. The alarm state (0, 1) was changed
to reflect the observed transition causing the alarm script to run.
5. Move the action for the script alarm to the script itself. Requires
a bit of backend shuffling as well.
6. Only create one script to watch all monitors. Easier to manage and
to present as service (which can be stopped and started if needed).