In an attempt to keep the database clean and hopefully error prone, the logger will export/import now every ~24 hours. As these operations are rather quick it should help to minimize the footprint as well (duckdb files keep growing after deletes).
closes https://github.com/opnsense/core/issues/7049
For testing convenience you can run the scripts separately and
add standard output and only standard error will be reported
once included in system_firmware_configure() or
# pluginctl firmware_reload
This commit omits some of the link-specific information such as ppp uptime, disconnect/release mechanism, as well as wireless and bridge information. Since there is more of this type of information available than was originally being handled by get_interfaces_info(), perhaps it makes more sense to extend the backend script with the relevant bits in time.
This commit adds the connection to the action.execute() method which offers the ability to flush data back to the client instantly without having to wait for the call to end. As the existing types are only slighly modified, the impact of this change should be rather low. To demonstrate the streaming capability, also adjust configctl to flush output when received.
Example usage:
[find]
command:find / ; xxx
parameters:
type:stream_output
message:test stream output
Offer configuration access for the kea control agent needed for high availabilty and basic peer setup.
o add Control Agent menu item with basic settings
o split dhcpv4 settings in general and ha
o add peer configuration
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.
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 commit adds a new component linked in Interfaces/Neighbors which offers the ability to manually register static leases and provides application control from other modules such as dhcpd. To minimize the risk, we're reusing the existing interfaces_staticarp_configure() hooks while only adjusting how static arp entries are being attached to the interface (match on addresses assigned when triggering with an interface).
Entries registered via dhcp will be visible from the ui as well together with its origin.
The previous version didn't cleanup old static entries, this version triggers a cleanup when executed for all interfaces using all earlier modifications processed via the same function (interfaces_neighbors_configure()).
This commit imports part of the changes from @swhite2 which will keep the legacy handling intact for the first stage of the migration. It should be backwards compatible with the previous (23.7.x) code.
Changes new in this commit which where not in the original PR:
1) dpinger_status() missed $gwitem which rendered gateways statusses down
2) Model version number set to 0.0.1 so we can use the migration later to step into 1.0.0
3) Gateways->gatewayIterator() do not yield MVC records ensuring we are still using legacy config data when being called.
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.
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
The idea of list_interfaces.php was good so let's take it further
and inline the use into legacy_interfaces_details() and moving the
patterns to a shared function. Also add a device name hint in case
the array key is not passed for some reason which can help when
inspecting debug data. Since legacy_interfaces_details() is already
available in pluginctl -D replace the action command and drop the
obsolete script.
Migrate ui to MVC, wrap model around existing configuration area to remain backward compatibility.
To avoid laggs configured via console not being reachable from the gui, add a uuid to it.
To allow legacy services without a model to hook into the `ApiMutableServiceController`, we define a protected `serviceEnabled` function that by default checks the given `internalServiceEnabled` property to see if a service is enabled, but allows derived classes to override the functionality. We loosen the property restrictions in `initialize()` by moving the checks to their runtime implementations.
DHCPv4/v6 is modified here to hook into this change, but since the `actions_services` requires the keyword `service`, which isn't used by the mutable service controller, we define start/stop/restart/status actions in the `actions_dhcpd.conf` and the new `actions_dhcpd6.conf` files.
