Speeds up lookup. The caller is ultimately in charge of operating
on the data given by the function. Most callers do not check the
return value for empty() so let's just fix callers that do require
this.
OpenVPN has had so many functions to reload and all of them hardcoded one
way or another. Since we already check CARP state in openvpn_restart()
and stop before potentially starting that should be enough indeed.
Another question is why servers are being restarted if CARP is solely
used for preventing to start clients on BACKUP nodes.
I have a little beef with the new code: the System: Gateways: Single
page listing should always list existing config.xml gateways, but it
does not. So it looks like a gateway was deleted when in fact it is
being hidden. This is definitely a visibility departure from the
previous code.
It only marginally matters and lan or opt1 is mostly there with
a safe assumption of no gateway unless that is for a different
purpose than simply going to the internet.
@Adschellvis and me wondered about this so I did a bit of
reseach and multiple workaround oddities exist to fix parts
of the issue. To be frank, fix the issue at the source and
do not let users otherwise configure these settings in tunnel
interfaces.
See: https://redmine.pfsense.org/issues/3280
Also see: https://redmine.pfsense.org/issues/8687
* always configure VIPs in interface_configure()
* also configure VIPs in rc.newwanipv6
* link_interface_to_vips() removed
* land IPv6 VIPs on the IPv6 device
Discussed with: @adschellevis
Trackers shouldn't be special in GIF and GRE and bridges. In
bridges there's also no use of VIPs so the code simplifies quite
a bit. Load all exceptions in a row with the "unhandled" ones
still at the top of the function.
What needs to be seen is if VIPs latch on to interfaces that
are handled as exceptions correctly, or else we will have to
reload them alongside again.
It's not equivalent because the _vip check wasn't correct and now
you can easily see the logic invert so that setup is either on '1'
or '2' and nothing can be missed.
Adapt newer code style techniques and try to separate convoluted
code into a clearer picture. This makes pluggable interface code
more attractive as we do not have to know up front how the interface
will look like.
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.
