This is certainly a downside of data migrations in general, when looking at the actual target, we don't have all the versions in between available. which means breakage is possible when skipping a lot of versions on our end.
* wizard: reimplement system setup, for https://github.com/opnsense/core/issues/8352
This commit implements our replacement for the setup wizard. The questions are roughly the same as in the legacy version.
Some less relevant options have been removed (pppoe ondemand for example) and isc-dhcpd has been replaced with dnsmasq.
Only standard tools have been used, a memory model to validate the data and simple input forms in tabs.
The in memory model acts as a wrapper around a legacy configuration data and a couple of component models to apply the requested settings.
Some legacy settings using isset() have been altered to use their empty() equivalent.
* wizard: as we're changing to dnsmasq as default, we need to make sure the console setup configures the same (https://github.com/opnsense/core/issues/8352)
Fix some small php arnings in the process, but further than that just rewrite the dhcpd console handling to use dnsmasq instead of isc.
Eventually we will need to rewrite the console tools as well, but let's try to keep this compatible with minimal impact.
* wizard: change other occurrences of isset($config['dnsallowoverride']) for https://github.com/opnsense/core/issues/8352
* wizard: sort listtags() and some other minor review comments for https://github.com/opnsense/core/issues/8352
For ipv4 there only appears to be a static mode type, ipv6 will extend the options. If we don't want to risk needing a checkbox for each of them, it's better to implement this as a mode dropdown.
* Captive Portal: WIP for migration to pf (https://github.com/opnsense/core/issues/8326)
Captive Portal: cleanup references to ipfw
Captive Portal: move accounting deletion to get action, update references and descriptions
Captive Portal: remove note
Captive Portal: move accounting to pf match rules
Captive Portal: cleanup and shorten code
Captive Portal: parser issue after refactor
Captive Portal: update logo in default login page
* Captive Portal: internal alias should not be editable
* Captive Portal: move to periodic accounting sync
* Captive Portal: update lighttpd zone config
* Captive Portal: ether rules for accounting
* Captive Portal: safe accounting fetch
* Captive Portal: move counter calculation to bgprocess
* Captive Portal: remove nested anchors, match anchors on interfaces as well
* Captive Portal: move service logic to captiveportal.inc
* Captive Portal: leftover test statement
* Captive Portal: properly initialize accounting result
* Captive Portal: cleanup sql
* Captive Portal: Implement backend requirements for RFC 8908
While here, the zoneid is provided to the client, even though there
there is no need to do so. Instead let lighttpd forward the
request with an added header containing the zoneid of the client
* Captive Portal: review feedback
* Captive Portal: from_not case
Rename previous "advanced settings" to "mobile & advanced settings" to guide people into the right direction, strongswan.conf contains both sets of data.
Keep legacy page for settings that are only relevant for the old components.
Since our pam authenticator hooks into the configuration, refactor to use the model as well.
Cleanup code in the model that was only used in the legacy glue.
* mvc/view: Ensure fields stay aligned relatively to another when headers are used in forms.
* mvc/view: Add style that forces consistency in smaller viewport sizes in base forms.
* mvc/view: Make classes more selective so the style does not leak when modal-dialog and form-inline exist in the same view (e.g. dnsmasq).
* mvc/view: Ensure the change in base_dialog is backwards compatible when msgzone_width is defined (e.g. in Intrusion Detection)
This commit changes PF.list_tables() to yield both the name of the aliases as well as (limited) stats, in places where we only check for totals, these are faster to collect than counting them in python.
There should be no functional impact.
When dnsmasq is not used for dns services, no default dns is being send to the client for dhcp.
Add a non specific option, which can be overwritten using tags.
In some cases it's practical to document the field so grids may use them, but skip them on input processing as the information is not that relevant to ask (or show using an info type)
Ideally these spots should not be needed as the frontend generates the configuration and on boot these are flushed as well, ... but, when interfaces change during boot or triggered by the wizard, these parts are not aware of these facts.
as discussed with @fichtner
In rare cases it is possible to lock the system during boot while drivers are loaded and tunables try to fetch all information from sysctl.
Since we already implemented a lazy loading pattern on the Alias model, it seems to make sense to push this up the chain and reuse it.
For consistency reasons, we should also push the "lazy" attribute when constructing new ModelRelationField types.
* vpn/openvpn: Implement base_bootgrid_table and base_apply_button for https://github.com/opnsense/core/issues/8318
* vpn/openvpn: overflow-y in column dropdown due to amount of items in grid
Add a note on top of the legacy pages about the end of maintenance, depending on version, this will be version 26.1 ot 26.4 [BE].
In the meantime components will move to plugins. When maintenance ends, it will still be possible to install the component, but may break unexpectedly.
This rather large commit implements most relevant dhcp options and rewrites dnsmasq's backend.
By default dnsmasq is disabled, eventually we do want dnsmasq enabled for dhcp services by default, but dns itself disabled. For this reason we support port "0" as implemented at dnsmasq (not listening for dns).
For cases where users want to integrate dns and dhcp services, the advise is to make dnsmasq listen on a non standard port and point unbound to the zones where dnsmasq is responsible for. This has the advantage of a direct connection between dhcp registered hosts and the requesting service. In these cases dnsmasq's dns service acts like a "connector".
In the long run we should deprecate `regdhcpstatic` and `regdhcp` as these either belong to legacy isc-dhcp or hook kea entries (which are better served via unbound).
The first mvc migration phase implemented IndexController.php, which we rename to SettingsController.php now as these results in more logical ui endpoints.
Since we don't bind to addresses directly (unless specifically configured and adviced only for static setups), we can skip the newwanip event which means we don't restart the service on interface changes. dnsmasq is able to filter the relevant networks on the fly, which is the advised scenario and can cope more easily with changes.
When different clients need to receive different options, we can use "tags" now. Requests can add tags to filter options which will be offered to the client, in the most simple scenario one would tag on a range or a host reservation, but more advanced choices can also be achieved using match statements (for example architecture [client-arch])
When services offer aliases which are less static, the current json option isn't very practical as we only want the package manager to ship files into these directories.
The new DynamicAliases namespace may contain simple php classes, which return a named set of aliases to merge into the set.
Since all of these classes are created on each alias query, it's highly advisable to keep their implementations as lightweight as possible.
* vpn/wireguard: Introduce latest-handshake-age to calculate if tunnel is online in backend. Implement it in wireguard.js widget and diagnostics.volt
* vpn/wireguard: expose peer-connected via API to approximate state of wireguard peers online/offline status, change status formatter to show statos of interfaces and peers, improve diagnostic grid
* vpn/wireguard: Move epoch calculation from frontend to controller
* vpn/wireguard: Track 3 different status instead of a boolean offline/online. Online means a handshake happened recently, Stale means a handshake happened in the past above a threshold of 300s, Offline means there was never a handshake yet. The same icons are implemented in the widget and the wireguard diagnostics page.
* vpn/wireguard: Remote peer disconnected translation since this is tracked by the icon now. Add stale translation.
* vpn/wireguard: Compact widget information for better readability
