This may have been going on ever since we moved a separate CORE_ABI
in the business edition. Fixed community mirror to accomodate for
23.4 and 23.10 for now as the bogons are the same anyway.
PR: https://forum.opnsense.org/index.php?topic=36886.0
Since pluginctl tells us which plugins are hooking into the
configure facilities allow us to select the plugin directly
like so:
# pluginctl vpn:wireguard
We use the delimiter ":" here as the configure already uses
it in the function end and it's unlikely used in a file name.
Both plugins_configure() and plugctl have no room to stuff
an optional argument somewhere, but the good thing is pluginctl
does not even need support for this and the PHP code could
use it too.
Make sure nobody gets the idea to do path traversal so strip
all "." and "/" characters.
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.
