Add two temporary spots that need to be reworked later when
this is verified working. Other plugins also register their
interfaces so it would be nice to pin them all down in a shared
hook.
Some back and forth between explicit and implicit requires while here.
The code is helplessly glued together and no plugin facility to get
data from a function call currently exists.
... so let's do that first and afterwards reload OpenVPN and IPsec.
It's not that problematic, because both variants reload the filter
when they have done something, so we merely spread out the call order
a bit instead of batching a number of filter reload at the end.
PR: https://github.com/opnsense/core/issues/2247
With this, there is consistency in setting the default route
and associated marker file. Nothing is done before the decision
is final, so we may not end up with a missing route after an
attempt to reconfigure for something that doesn't work anyway.
DHCPv4 and PPP still do this manually, but we will have to route
them through the same logic instead of them manually handling their
routes. 6rd and 6to4 may have a similar issue as well.
While here, swap the system_routing_configure() arguments to
align with the way other configure functions present their
arguments (verbose print flag first).
Gateway monitoring and default switching improvement since 2016.
Push $keep into default handling, it may be useful in general to
avoid spurious switches. It could also be a default probably.
We have a function pair rrd_import() / rrd_export() now, which do
wildly different things even though they've been used for a single
purpose:
(1) rrd_export() writes a string, appends it to the config.xml
(2) rrd_import() takes a parsed config portion, but not as an
argument, rather as a global config element
(3) There was also an older backup clue which exported files, but
simply packed them up for restore after boot
If we can get the system to unify the usage we'll end up with a
neat way of backing, restoring and migrating RRD data, although
I'm not sure if this can be fully compatible with the old files.
Looking at openvpn_configure_server() and openvpn_configure_client()
it becomes a bit clearer why they take a config.xml subset: it's beause
the write_config() ordering was flipped. We could probably now pass
an ID and let the code figure out if it is a client or server...
Early installer is really about an untained system, so
we defer *all* system setup and only keep the loopback
configuration above it. This way, after config import
from the installer system_login_configure() is up-to-date.
