* 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
Take our chances with SSH. It looks like using 'early'
facility surfaced this problem that was not as trigger
happy before. The administration page does the same.
PR: https://forum.opnsense.org/index.php?topic=43995.0
Time to ditch this. Leave a thin dialog for the ports display
and where to access the actual PPP settings.
page-getserviceproviders now folds into page-interfaces-ppps-edit
and remove only once use functions to edit page as well.
This always bugged me: 'newwanip_map' is called when e.g. DHCP is
done but here we just do it async to start something. This doesn't
make sense, because eventually it triggers twice.
What rc.reload_all and setports.php do is call 'local' and I think
that makes sense.
Add RRD package with a simple factory class and a basic construct to define different rrd output types we support.
This package contains the following:
* RRD/Types -- Output definitions, responsible for generating RRD structures and feeding data
* RRD/Stats -- Statistics gathering classes
* Factory -- binds types and statistics together.
On my end on a simple test this is roughly 40% faster than running /var/db/rrd/updaterrd.sh, which makes caching of metadata (config access) less relevant.
The new script should be able to replace all existing rrd cruft and supports a debug mode to find discrepanties between defined outputs in types and collected data in stats.
```
Usage: updaterrd.php [-h] [-d]
-d debug mode, output errors to stdout
```
Unify the situation for 'ppp_port' vs 'ports' use by using the latter
as is. One of the issues of this page always was inconsistency after
all. Then also zap the validation that causes the changes not to be
accepted. In theory it's posted anyway but that has been the case for
PPPoE/L2TP/PPTP since the fork.
One of the nice things is that we don't have to do the global
loop but get all of the information across at once even if
individual listeners will still loop over it if necessary.
As discussed with @AdSchellevis make this a reality for
PPP/PPTP/L2TP, but leave PPPoE as is for now. This
allows inline creation of PPPoE to remain for the time
being.
Inline removal, OTOH, is removed hereby since buggy.
This change reflects what PPP is actually capable off under
the hood and no functional changes intended.
You could still post a different type but since the goal is
to get rid of posting anything related to PPP this will make
it easier to judge if people actually used this.
We want to avoid modifying ports for the PPP devices and
rearrange the type feed slightly. Most of the PHP warnings
on this page relate to PPP trickery that will go away.
Next step will be only offering the matching IPv4/6 types.
Fix one valid warning while here.
We have to revoke being able to set "random" here for now, but
it's not a huge issue since the fallback is now in the daemon.
The daemon also supports the full unsigned long long range but
does not allow hex input which means we are stuck with losing the
highest bit for now if we store in integer in PHP.
We could store a string, but then cannot verify it and it would
not be a hex value. Meh.
For some reason it convinces me further that we should fix the
ifid default case with a fallback in dhcp6c because users will
not necessarily make that connection and just raise a bug report.
The situation is a bit complex involving rtsold, the accept_rtadv and
the system configuration for WAN and LAN. Will see if we can find
another way to discourage the use of the SLAAC address. I don't think
we really really need it.
While here restructure and reword some of the options. Also
add a possibility to disable the SLAAC address which complements
this nicely and has been known to be problematic for some users.
For dhcp type interfaces, gateways are being pushed by the server and we automatically assume these are "external". For static ones you can configure similar behavior, but only explicit. When selecting a gateway, both reply-to and source nat rules are affected.
When nothing is chosen (now default, earlier "auto-detect"), normal routing rules apply and nothing special happens.
Separate use cases to allow for clean non-removal of static addressing
(including CARP VIPs) for use in rc.linkup et al. While interface_bring_down()
is more or less only being extended with $suspend the journey of this code
change was long and winding. Therefore remove the old ambiguous function
and introduce the new interface_reset() and interface_suspend() variant to
make more sense of the caller's requirements.
interfaces.php is a special case depending on interface enable state so we
pass the $suspend request down to interface_reset() to avoid an if-else
dance.
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.
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.
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 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.
This simplifies the call a little and allows us to do better recursion
away from config-based interfaces. We could just pass the device as
the interface and it would work but then we pass it down twice and it's
not very readable.
This requires to set up the VLAN priority field of the
DHCPv4 settings as well as removing the vlan-pcp option
which is redundant now. This way we have a simpler
approach to finding the correct value while not borrowing
from IPv6 or parsing the advanced options for vlan-pcp.
Leaving the old vlan-pcp in place should not matter.
The last value is ours and this one should be used.
PR: https://forum.opnsense.org/index.php?topic=33376.0
