Our current default (legacy) scenario is to use the configured interface addresss as gateway and primary dns, but since we don't want to complicate the templates and make the choice explicit, we're adding an option to auto-collect and persist on configuration save/apply.
This commit auto updates selected option data fields on request with the first matching address for the requested subnet found in ifconfig.
This commit moves the default logic into the model so we can reflect current values into virtual fields.
For all relevant "dpinger" fields, we reflect the current value in a field named current_$field, which means we can always query the active value without touching the stored one. Determination of current is as easy as `!empty(model_value) ? model_value : default`.
Refactor the dpinger process to use the current_ fields, since "dpinger_status()" retrieves all instances including the ones not stored, safeguard the config properties to exclude status determination (as loss and latency fields don't exist).
Previously the validation messages seemed to miss some gettext(), re-add these as well and cleanup validation. By calling isFieldChanged() on the array type, we know the gateway object has changed, but not exactly which field, this might lead to some noise, but if we implement a fix for https://github.com/opnsense/core/issues/6978 , we should be able to avoid real issues with the bonus of needing less code.
The calculateCurrent() on the GatewayField ensures we can insert/update the current values after an update as these are nog aware of modifications automatically.
Finally, respect the 120 character screen limit.
When there are invalid gateway items, it's likely better to skip the ones that we can not migrate in this case. Executing the validation on every record might be expensive, but likely leads to a more consistent end-result. After migration, make sure to remove the old cruft when we end up with at least one gateway.
Without "AllowDynamic" on the intreface selector, we will miss dynamic interfaces like ipsec vti's.
Where the first stage primarily aims to keep the legacy handling of gateways intact, this stage does the conversion to MVC.
As part of the migration strategy, configured gateways will not be touched if the migration fails. This allows users to repair the gateways in the new situation.
This commit contains the basic features of our new DHCPv4 server, it certainly needs additional testing as currently we only validated the configuration format is valid. The aim is to keep the json templates as simple as possible.
For now we keep the kea-control-agent disabled, we probably need it later, but we don't want to expose a listener without using it.
This way we can see if something changed and reboot if "always
reboot" is required. We do the first hash unconditionally because
it's fast and maybe we can use this for other purposes as well.
The way this works is a little funky...
1. For console calling update script it will ALWAYS reboot,
but at least it says so. We simply do not know how much
will be updated / is available but that is by design
leaving this as a capable fallback option that will work
even if the GUI has issues. That's also true for no
updates being installed... it reboots by virtue of
calling the update script into active duty.
2. The GUI and API will have the reboot flag set and know
this beforehand, but will prevent calling the script
when it isn't going to do anything. This makes the reboot
behaviour better, but ideally we also need to know if we
need to abort the reboot based on package install progress
which we currently do not check.
That being said the feature is fine to use when updating the
box via GUI/API/OPNcentral on a regular basis without messing
with the box too much in between. It's not tailored for micro-
mangement so it should only be used where the behavior fits
the requirement of a consistent system state after firmware
updates (and not hammering the update server every hour for
hotfixes which will make it reboot also).
I guess we need to make further changes, but this is a good
step nonetheless.
No change in behaviour yet, but funnily enough the channel list
build got easier and the previous code makes sense now...
Since we are dealing with a lot of duplicated channels now it
further points to restructuring this into a merged select for
mode, channel and width as this is how the driver operates.
if the gateway structure contains a <gateway_item/> as first element, technically speaking $config->gateways->gateway_item is empty. Better to check for children when gateway isn't empty to prevent none of the gateways being rendered in these cases.
setconf can fail for DNS resolution reasons. It is being considered
a configuration parsing error so nothing gets set on the instance.
However, our code remembers that the instance was fully set up although
that is not the case. The newwanip event was handling DNS renew but
does not understand that the configuration is not complete.
Replacing reresolve-dns.py by doing syncconf works, but this is used
as a cron-based script and likely does the job it is intended for.
Instead rehook the newwanip event into a simple syncconf invoke which
takes "more" time (according to the man page) but won't touch existing
peers being connected while still fixing any configuration mismatch
in the (possibly stale) instance.
Channels for "list chan" and "list txpower" may be in a side by side
2 column layout which makes the current parsing fail and miss half
the channels. Replace the parsing with "sturdy" regex to collect all
the results and also make sure that all modes and fallback modes have
the actual channel information. Also clean the templating in the
static PHP file a little in related areas.
This commit addresses a couple of possible issues.
1. When a sequence of carp events is being processed and these processes lock eachother, its possible that collected interface state via legacy_interfaces_details() doesn't match the active one anymore. To prevent this from happening, only fetch the wireguard interface we're interested in inside the lock.
2. To limit the number of events being handled in wg-service-control.php it's likely cleaner to push the vhid as well when we're handling carp events. This means that we should switch between server id (current parameter) and vhid by looking at its format.
3. In case the target (wg) interface doesn't exist, make sure to create it. Although in practice this shouldn't happen (as the stat file is being removed on boot), dropping an interface manually should preferably lead to a funcitonal setup anyway (otherwise it will crash trying to pull it up)
4. When a vhid is passed and affects the interface in question, log relevant information to syslog.
When migrating Category this fails with an error:
Fatal error: Uncaught Error: Call to undefined method OPNsense\Firewall\Category::flushCache() in /usr/local/opnsense/mvc/app/library/OPNsense/Firewall/Util.php:176
Stack trace:
#0 /usr/local/opnsense/mvc/app/models/OPNsense/Firewall/Migrations/M1_0_0.php(103): OPNsense\Firewall\Util::attachAliasObject(Object(OPNsense\Firewall\Category))
#1 /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php(711): OPNsense\Firewall\Migrations\M1_0_0->run(Object(OPNsense\Firewall\Category))
#2 /usr/core/src/opnsense/mvc/script/run_migrations.php(54): OPNsense\Base\BaseModel->runMigrations()
#3 {main}
thrown in /usr/local/opnsense/mvc/app/library/OPNsense/Firewall/Util.php on line 176
