Most of this code is quite old and originates from the beginning of our project. At the time it seemed to be problematic to render the full rrd stats in a d3 graph, which required the "resolution" option for faster page loading. It looks like we can safely remove this toggle and ditch quite some code in the process. There's still room for improvements in the html/javascript part, but that's probably for another day.
This commit also simplifies the api usage as unused parameters are being removed from the callers (from, to, ..)
* Update ipsec.widget.php
This change solves the problem of users having multiple IP addresses as leases and being counted per leased IP.
- Only "user" are counted now
- Each "user" can have several "lease"
- Each "lease" can have an individual online or offline status
- A user is online when at least one "lease" is "online = true"
* Update ipsec.widget.php
- Replaced multiple "array()" with "[]"
- Access keys "user", "address" and "online" directly from the $lease array without storping them first
- Merged two seperate foreach loops into one
o fix merge issue, as system_gateways_edit.php is not used in the new version, we do need to make sure it's hooked to the new code in master first. At a first glance dpinger_defaults() is the only missing part now.
This commit imports part of the changes from @swhite2 which will keep the legacy handling intact for the first stage of the migration. It should be backwards compatible with the previous (23.7.x) code.
Changes new in this commit which where not in the original PR:
1) dpinger_status() missed $gwitem which rendered gateways statusses down
2) Model version number set to 0.0.1 so we can use the migration later to step into 1.0.0
3) Gateways->gatewayIterator() do not yield MVC records ensuring we are still using legacy config data when being called.
When multiple interfaces are selected, these will render into separate rules in which case it might not be clear what the outcome would be, specifically when choosing something else than "pass" (pass lan,wan would lead to two rules which match either lan or wan, block lan, wan would lead to random behavior for example).
For https://github.com/opnsense/core/issues/6902
Before: server, client, local, endpoint, peer, interface, instance and
tunnel adapter were being used some times meaning the right thing but
often also displaced.
Now we try to stick to instance (a wireguard interface in its config),
device (pertaining to the actual network device in the system), peer
(a wireguard peer in its config) and endpoint (the actual "endpoint"
setting in a wireguard peer config).
But we can only rename the user facing GUI parts. The API and config
structure will not change.
While here also update the model and tweak a few form labels and help
texts.
Omit the dependency on wireguard-kmod as we will be targeting the kernel
module with 24.1. Some people may run into this but it's safer than
trying to rely on a package that won't be available going from 23.7 to
24.1.
Once upon a time we tried to treat this script as an external one
since it's still maintained somewhat in FreeBSD but the approach
of integration is much different so the script ends up with half
of its code not doing anything and perhaps more than it should.
Upstream fixes are also not full applicable anymore.
* Clear the writing of the host name. The system does that. Simply
keep the logging aspect of it (if given).
* Remove the $ARP flush on TIMEOUT/EXPIRE as it seems misplaced.
* Remove exit_with_hooks() and is_default_interface() as these are
tools that are not needed in our integration approach.
* While trailing TIMEOUT/EXPIRE failure case make sure to run
newwanip in optional mode in order to pick up missing configuration.
* Copyright the changes from 2021 onwards that offer substantial
changes to the way the script integration works or cooperates with
the rest of the system.
* Inline the one-time use of functions.
* Remove tip-toeing around $resolvconf_enable.
* Ignore dhclient-enter-hooks.
* Remove commented-out code.
When \Deciso\OPNcentral\Central exists, there might be multiple providers to select from, so we can easily reuse the same component in both versions.
closes https://github.com/opnsense/core/issues/6828
Local backup configuration would be best stored in the backup configuration for consistency. Eventually we should refactor the backup configuration as well, but while refactoring the history page and adding a host selection (when used in conjunction with OPNcentral), this setting is a bit out of place.
