This was refactored previously and all the logic should live outside
dhclient-script but it seems it's only loosely handled over there.
For now put a check back in the old way and rework this later correctly
from the system.inc point of view: we do want to register nameserver
and searchdomain in the cache files, but should not add a route if
those are not required. It would be helpful to show them in the overview
regardless (as for DNS servers) but with a hint that they are not being
used.
PR: https://forum.opnsense.org/index.php?topic=26765.0
1. IP alias was not properly selected when editing after save.
2. VIP detection was only aware of CARP address.
3. Simplify the overview by printing the interface only for CARP
to unify all 3 cases.
This easily overlaps daemons and depending on lock structure
and other serialization two daemons could easily deadlock or
play ping-pong over rc.link start/stop situations.
The history of this dates back to m0n0wall and it seems what
this tries to achieve is restarting an instance of mpd that
will dial on demand later on so the idea is to start the service
when deconfiguring it. That might seem "clear" but structurally
there's no reason to run a single shot configure during interface
disable step (likely through rc.linkup stop).
An ancinet dragon was woken from its slumber while reworking the interface
configuration code. All things considered this is more than reasonable
although we do not yet know how this condition can be reached now as opposed
to 21.7 and if the inline termination of mdp5 will not invoke any sort of
deconfiguration (ppp-linkdown) that would harm the impending start of the
service.
PR: https://forum.opnsense.org/index.php?topic=26652.0
The far gateway flag has some benefits for configuration runs
and validation purposes on the GUI but in the end after lots
of reworks we are able to reliably get a network from the interface
to put the default route on so that we can detect if we are in
need of a far gateway or not. This is required for automatic
gateways on DHCP that hand out these situations while the
gateway code should not be in charge of flipping on the fargw
bit as it does pertain to runtime interface configuration.
Leave the fargw configuration flag in place for now to let people
test this, maybe backport it earlier and look at fargw more
closely in the remaining use case(s).
o Merge defaults and requirements.
o Get rid of get_default_sysctl_value().
o Manually set 'type' for e.g. boot enviroment tunables.
o Cache sysctl map once per boot.
o Edit system defaults for easier override.
While sysctls might change when (un)loading kernel modules the
risk of missing something vital is not given. We could always
flush the cache file in that case later.
