Not pretty. Need to hook wireguard-kmod on life support for
the initial 24.1 at least because we don't know at build time
if the kernel to be installed will have its own kernel module
or not. Having both works, but the kernel one breaks wireguard-go.
Also implementations for kernel and port kmod seem to be "slightly"
different.
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.
Testing 3582242d0fe10 it appeared that link-local addresses were
rewritten as GUAs in the dhcpd configuration. The static map part
does this right, but all the other callers are not. Flip this
around as it was intended. The DHCPv6 page will now throw an out
of range error when it previously adjusted the explit prefix anyway.
dhcpd config with link local seems fine too, but more testing is
always good.
MaskPerItem=Y needs work and the preg_match() shoudldn't be used
to look inside the match which creates the initial problem:
/usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiControllerBase.php:176:
Error at /usr/local/opnsense/mvc/app/models/OPNsense/Base/FieldTypes/CSVListField.php:162 - Undefined array key 0 (errno=2)
If we ever derive from UnqiueIdField we would end up overwriting
this message and there is no data validation involved which the
message would be for so it can be null as per BaseField.
The validation message is never seen anymore and can't be overridden.
While the field made sure to emit a message on empty the result is
that if we ever have to use this group field as optional we would have
to pivot to this approach anyway.
