Small addition to https://github.com/opnsense/core/pull/6050:
- Move private/insecure domains to advanced as its intended use has a larger scope than DNSBLs only. Fixes https://github.com/opnsense/core/issues/5256
- Extends the migration to also include these domains.
- leftover cleanup of legacy settings in migration.
- Adds the `serve-expired-reply-ttl`, `serve-expired-ttl`, `serve-expired-ttl-reset`, `serve-expired-client-timeout` options. These options are hidden until the `serve-expired` checkbox is checked, and indented to signify a relationship.
- Removes all dropdowns and instead provides numeric fields to input raw values for more control and less "guessing" of what is acceptable.
- Removes default settings to prevent mismatches with upstream in the future. It's probably best to refer to the Unbound documentation in our own documentation.
- Previously, `rrset-cache-size` and `outgoing-range` were implicitly set. These are now input fields. The migration code will take care of legacy setting assumptions.
Fixes https://github.com/opnsense/core/issues/5978
Fixes https://github.com/opnsense/core/issues/5795
While here, simplify code as well, only store validation output (size, fingerprint) in model itself, although it would be cleaner to send this information via the controller (as overlay), it would mean duplicate work here.
Found while testing https://github.com/opnsense/core/issues/5636
In some cases early DNS works with direct upstream queries for
fixed DNS servers. For DHCP or other dynamic connectivity it
will likely never work as expected with interface-related host
lookup requests.
At least try to load /etc/resolv.conf along with /etc/hosts and
refresh when all interface configuration is active. This needs
to rely on running configuration to pick up DHCP and the like
as said before.
Adds a bit of code on the initialization but allows to trace the
information without magic globals.
Has been on the wishlist forever, but nowadays it's simple enough
to replace the few instances using it.
opnsense-update -K will handle subscription key return if found.
Fetch the license metadata if it exists, move it to core version
meta file and handle the contents dymanically if it exists.
The only issue for later is that changing the mirror away from
business we have a lingering license file until the next check
for updates is done.
At the moment it doesn't seem to make much sense replacing the IXR library, the latest release tag from https://github.com/kissifrot/php-ixr seems to be from a couple of years ago as well and most changes relate to splitting the file into separate class files.
Extends check.sh to fetch license json file when a uuid is found and flush this to /usr/local/opnsense/license.json.
The firmware page adds a license validity row, which is hidden by default and only shown when product.php returns 'product_license_valid_to'.
For the dashboard widget we'll add the "licensed until" string to the core product string when available.
o bulk insert <tr/> objects to prevent overhead finding the top item in the list
o fetch with a minimum of 1000 records, so the browser has something to apply filtering too, this also prevents the issue of not being able to find results when > 25 records per second arrive. Processing 1000 visible records is a lot more effort for the browser than handling 1000 invisible ones.
o simplify table cleanup, as records over "max_rows" would be dropped anyway.
```
$fw = filter_core_get_initialized_plugin_system();
filter_core_bootstrap($fw);
plugins_firewall($fw);
filter_core_rules_user($fw);
```
Above block should offer a complete view on the firewall rules now, which we may use in the gui as well. There's still an idea to offer a full view on all firewall rules that apply to an interface (including floating and groups), a bit inspired by this request https://github.com/opnsense/core/issues/6024. In order to do this, we should likely be able to offer a single rule provider first so we can just query the object.
Since filter_rules_sort() is only called via front end pages, it should be safe to check if rules already have a uuid assigned and assign them if they don't. This prevents a migration and increases the change of fast adoption of the rule uuid's.
This commit adds generate_uuid() to config.inc and mimics the same behaviour as mvc models will do, if at a later point in time we would like to hook uuid's to xml attributes in other areas as well, we can simply reuse this.
It is likely a good idea to start using the uuid's in filter_core_rules_user() as labels too as this would prevent the use of the rule hash calculation (saves time and is a more stable id in most cases).
Impact of this change should be rather low as nothing depends on the uuids yet.
