Adds a reporting backend for Unbound as well as a dashboard showing an overview of interesting statistics:
Total DNS queries (over a maximum period of 7 days)
Blocked queries
Cache hits
local-data hits
A traffic graph with variable intervals
top N passed/blocked domains (with associated blocklist)
There are a couple of hardcoded values:
The underlying database is kept up-to-date for the last 7 days.
The ring buffer used to decouple unbound from the logging backend has a size of 100000 entries.
In very busy networks, db commits are done for a max of 4000 entries, which according to testing seems to be a good break-even point for DNS throughput vs. insert performance. Everything below this is flushed to the database every 5 seconds.
To facilitate the variable interval traffic graph, multiple views with varying detail in time slots are created: 1, 5 and 30 minute buckets. These can easily be extended should different intervals be necessary.
Not going to backport this, but in 22.7.x unique was called uniqueids and forcefully set to "yes", which according to the documentation (https://wiki.strongswan.org/projects/strongswan/wiki/connsection) is not compatible with a closeaction as this might lead to an avalanche of reconnecting children for the same connection. Although swanctl (https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html) doesn't explicitly mention an incompatibility, our defaults are different than the ones being configured nowadays. Adding the option does seem to make sense.
Media settings probe is suboptimal for hardware detection and
interfaces_hardware() already uses the function to decide where
to enforce hardware settings.
PR: https://forum.opnsense.org/index.php?topic=30923.0
this eases scriptable actions where a single unique entry should be pushed atomically to multiple hosts.
e.g. the below would add/set an alias named api_test_001 :
r = requests.post(
'https://192.168.1.1/api/firewall/alias/setItem/9a8fc804-0000-0001-99cb-283ca2d04e58',
verify=False,
auth=(api_key, api_secret),
json={'alias':
{
'enabled': '1',
'name': 'api_test_001',
'type': 'external',
'counters': '0',
'description': 'api_test_001'
}
}
)
print(r.text)
In theory we should be able to move the host routes for 6rd and 6to4
easily without repercussion, unless some part of the system tries to
reload the interface without calling system_routing_configure().
While here simplify the host route creation as we want to split
this out for a clean reset during a full routing table reload so
we can be sure all stale and disabled instances are removed anyway.
