Cleanup alias handling uniforming operations so new types can be adopted more easily.
o move all pf actions to it's own class
o move all alias related modules to l`ib/alias`
o move AliasParser to alias.py to make update_tables.py more readable
o add targetted alias (type) updates (update a list of aliases including dependencies)
o cache non managed aliases as well, so targeted updates have the opportunity to nest these (interface or bogus aliases for example)
o refactor cleanup a bit to store and keep "txt" files for external aliases
o add `BaseContentParser` type which should be inherited by all parsers and wrap existing types into the new base class.
o add unit tests for all current parsers.
We are forcing a renew now when required anyway and if we keep the
cache file we can flush when it matters and bridge the gap between
same IP addresses with a non-address reload being triggered in between.
Go the extra mile now that we know we reached the bottom of the
barrel with reload functionality. The new guard is already working
so we can unconditionally run the second half as we already do in
IPv6 variant.
Eventually the old gui code should be replaced as well, but this is an easy to release step in between offering nearly the same output (p2p's presentation is aligned with server in stead of client) with code we are able to reuse for the openvpn aliases.
In case addresses are removed and reapplied the routes are gone
and other related interface configuration is missing. In these
cases do a full recycle even though the address did not change
visibly (which is good that we can detect it).
Also address the "miss" of the cached address clean now that we
know DHCP should not force-update us into a missing address
scenario during a renew.
PR: https://github.com/opnsense/core/issues/6338
As lighthttpd's changelog (https://www.lighttpd.net/2023/1/3/1.4.68/) notes the module is deprecated and can be replaced by mod_magnet with lua script.
Since the firewall offers rate limitting as core feature, we might as well remove the fixed (hard) limit in CP and point people to the firewall rules if needed.
There is a log message "2023-02-12T14:33:48 Warning ntpd restrict: 'monitor' cannot be disabled while 'limited' is enabled" ever so often when rate limiting is enabled. Disabling rate limiting is not advisable and even then, there will be another warning because certain combinations of rate limiting and kiss-of-death are chosen. ntpd options should probably be overhauled anyway.
However, according to the referenced https://www.cisa.gov/uscert/ics/advisories/ICSA-14-051-04, this issue has been fixed long ago. The current version 4.2.8 of ntpd is not longer vulnerable to this, such that "disable monitor" is no longer neccessary.
