This inline-assign shouldn't happen anymore (likely a very early version
using the wlan device name implicitly). Maybe for 25.7, needs a tiny code
audit at one point but since the other cruft changes are in 25.1.3 this
makes sense to push.
First these are sane defaults, second they always belonged to NTPd which
we do not configure in the wizard. The settings are now contained
within network time/ntpd and just need a proper migration when the MVC/API
conversion for that component begins.
We never rely on xml ordering, which means a "nosync" can always be appended or prepended into an existing dataset (as long as uuid's don't overlap, but that's a bit of a corner case).
This commits tracks the nosync items inside the dataset to sync and prepends them to the new target set, so all nosync items on the back remain where they belong.
The $sync_full construct always looked a bit weird, certainly as different other comparable config sections don't seem to have the same issue as mentioned in the original commit (1b99e1e53a). Tried the nat rules on an existing setup after this change, which still works like a charm.
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
