Exception: Failed to parse time string (+ days) at position 0 (+): Unexpected character in /usr/local/opnsense/mvc/app/controllers/OPNsense/Trust/Api/CrlController.php:347
Stack trace:
The rotate function needed the next file to calculate the suffix, which is problematic if someone just cleaned all logs. This patch improves the match a bit (last _ instead of assuming _ doesn't exist in the name) and uses "1" for the first rotate action.
Also some minor performance improvements as suggested by https://www.chartjs.org/docs/latest/general/performance.html.
in contrast to the old dashboard memory calculation, this widget does not consider ARC to be part of used memory anymore.
Remove the previous link from the user to the certificate as this suggest some relation between the two that doesn't exist (other than the name).
In the userview, the certificate list contains all client certs with the same commonname and verifies if the logged in user is able to access the trust module to prevent data leakage.
closes https://github.com/opnsense/core/issues/7387
When downloading files, throw errors and handle them in _blocklist_reader() so ew can decide to use the original cached one if still available. Move error handling to the same spot.
closes https://github.com/opnsense/core/issues/7371
fetch(1) appears to return "Unknown" when not being able to
get the size of the file from the mirror. It's a bit odd
considering the code in question didn't change for years on
all ends and so far nobody reported a similar issue.
The calculation isn't strictly necessary as we try to fill
the gap between pkg integration and extra sets that should
be handled by pkg-base eventually.
This is a bit of a chicken and egg situation, the streaming plugin
requires knowledge of the datasets (even if the actual datapoints
are empty) as soon as the chart is rendered, but the metadata is
only known after the first server response.
Extend Firewall/Util to iterate over a cidr range, so we can fetch the first available here.
The address fiels should be the "Allowed IPs" in the peer on this instance end. When using allowed IPs ::/0, 0.0.0.0/0 on both ends, the tunnel should work as well, but may people confuse about the routing part.
When the remote end sends traffic from addresses other than the ones configured on the tunnel, one needs to update the peer manually.
In most cases we use config locking, the lock is acquired only once, in which case all works as expected.
When a controller fetches a lock and passes it on to one of the core controller wrappers which then re-acquires the same lock, the default is to load the config again.
Pending data in other models will be flushed in these cases, which is unexpected if we're updating the same config, but a different section.
This change only executes the reload when not yet locked by this process.
