Since pluginctl tells us which plugins are hooking into the
configure facilities allow us to select the plugin directly
like so:
# pluginctl vpn:wireguard
We use the delimiter ":" here as the configure already uses
it in the function end and it's unlikely used in a file name.
Both plugins_configure() and plugctl have no room to stuff
an optional argument somewhere, but the good thing is pluginctl
does not even need support for this and the PHP code could
use it too.
Make sure nobody gets the idea to do path traversal so strip
all "." and "/" characters.
This commit moves the default logic into the model so we can reflect current values into virtual fields.
For all relevant "dpinger" fields, we reflect the current value in a field named current_$field, which means we can always query the active value without touching the stored one. Determination of current is as easy as `!empty(model_value) ? model_value : default`.
Refactor the dpinger process to use the current_ fields, since "dpinger_status()" retrieves all instances including the ones not stored, safeguard the config properties to exclude status determination (as loss and latency fields don't exist).
Previously the validation messages seemed to miss some gettext(), re-add these as well and cleanup validation. By calling isFieldChanged() on the array type, we know the gateway object has changed, but not exactly which field, this might lead to some noise, but if we implement a fix for https://github.com/opnsense/core/issues/6978 , we should be able to avoid real issues with the bonus of needing less code.
The calculateCurrent() on the GatewayField ensures we can insert/update the current values after an update as these are nog aware of modifications automatically.
Finally, respect the 120 character screen limit.
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.
This commit contains the basic features of our new DHCPv4 server, it certainly needs additional testing as currently we only validated the configuration format is valid. The aim is to keep the json templates as simple as possible.
For now we keep the kea-control-agent disabled, we probably need it later, but we don't want to expose a listener without using it.
setconf can fail for DNS resolution reasons. It is being considered
a configuration parsing error so nothing gets set on the instance.
However, our code remembers that the instance was fully set up although
that is not the case. The newwanip event was handling DNS renew but
does not understand that the configuration is not complete.
Replacing reresolve-dns.py by doing syncconf works, but this is used
as a cron-based script and likely does the job it is intended for.
Instead rehook the newwanip event into a simple syncconf invoke which
takes "more" time (according to the man page) but won't touch existing
peers being connected while still fixing any configuration mismatch
in the (possibly stale) instance.
This commit addresses a couple of possible issues.
1. When a sequence of carp events is being processed and these processes lock eachother, its possible that collected interface state via legacy_interfaces_details() doesn't match the active one anymore. To prevent this from happening, only fetch the wireguard interface we're interested in inside the lock.
2. To limit the number of events being handled in wg-service-control.php it's likely cleaner to push the vhid as well when we're handling carp events. This means that we should switch between server id (current parameter) and vhid by looking at its format.
3. In case the target (wg) interface doesn't exist, make sure to create it. Although in practice this shouldn't happen (as the stat file is being removed on boot), dropping an interface manually should preferably lead to a funcitonal setup anyway (otherwise it will crash trying to pull it up)
4. When a vhid is passed and affects the interface in question, log relevant information to syslog.
We don't even need the full rc.configure_firmware script as that
is for after a core package was updated. Rather we just want the
actual firmware settings to reload so we add a different path for
it. Now it is faster than it ever was.
Ok, so now we work with 1.20 but cannot use it because we can't render
the repo file before pkg updates itself and causes it to malfunction.
That means we cannot add 1.20 before 24.1.1.
Even if we fixed our mirror to be SRV compatible two facts remain:
1. We cannot control third party mirrors which will likely all be
plain HTTP(S).
2. pkg 1.20.x from FreeBSD will still break firewall operation and
upgrades if left on the system so we make the situation better now
to bite the user later on.
Since we used to allow IP configuration ands VIPs are
a possibility we can avoid checking for missing IPs
and simply delete the status hash file which will
force an eventual reconfiguration.
While here avoid wireguard_prepare() from creating spurious
devices when there is no need for it as it happens with
manual invoke through "pluginctl -d wgX". wg-service-control
uses the same logic.
This commit adds a new component linked in Interfaces/Neighbors which offers the ability to manually register static leases and provides application control from other modules such as dhcpd. To minimize the risk, we're reusing the existing interfaces_staticarp_configure() hooks while only adjusting how static arp entries are being attached to the interface (match on addresses assigned when triggering with an interface).
Entries registered via dhcp will be visible from the ui as well together with its origin.
The previous version didn't cleanup old static entries, this version triggers a cleanup when executed for all interfaces using all earlier modifications processed via the same function (interfaces_neighbors_configure()).
Since OPNsense 22.1 we are using FreeBSD 13 and it comes with a
base trust store which is also maintained there. In order to be
user-configurable there is also a tool called certctl which will
manage blocking and filling the OpenSSL trust store location
/etc/ssl/certs. The idea is to make this implicit and faster.
This, however, pseudo-obsoletes the trust bundle handling which
we mainly operate through /etc/ssl/cert.pem. By pseudo I mean
that ports will still want the real bundles and/or know/guess
this location at complile time. curl has such overrides for
example.
ca_root_nss's bundle is also pulled in thorough certctl so we
are going to have to jump through a few hoops now in order to
add our certificates cleanly and "prevent" breakage of the
resulting trust store.
Therefore now we write our CA content into separate files because
certctl only hashes the first certificate found in the file.
This is already a bit problematic for ca_root_nss having a
larage number of files in it... And against all odds the
first certificate I wrote for our bundle is blacklisted by
FreeBSD which made certctl discard all OPNsense authorities
added from the GUI.
To avoid further issues with certclt as a broker here I have
added it in passthru() mode to see eventual errors clearly.
Now when certcl is done all the files are linked in the
/etc/ssl/certs directory but we actually have to build the
full bundle for compatibility with old ports requiring one
of the locations that ca_root_nss ETCSYMLINK option provides.
A shortcoming of certctl is the lack of a bundle mode for
compatibility's sake which is causing a number of problems in
the ports tree at the moment (which is why we do this work now
and take a closer look before this is rolled out in full in
FreeBSD ports).
The bundle is created by iterating over all files in /etc/ssl/certs
and putting them in the expected locations. One caveat is that
this bloats the bundles to 1.5MB from previously 750KB. The whole
process is a lot slower, especially certctl doing the rehash.
Long story short: this is going to cause issues in the long run,
but for now we know how it is supposed to work and are ready
for FreeBSD ports to drop support for bundles in individual ports.
But that being said we will probably drag the bundles on for
a few years anyway.
This can slow down reconfiguration of a system with many
VLAN children on a single interface down/up. We likely
have to refactor rc.linkup to coalesce the interface
reload into a safer reload facility.
This is called through rc.linkup exhibiting the issue.
Sidestep the complexity of the situation by fixing the
issue first making it testable and easy to ship in a
stable relese.
For anyone not liking this net.inet6.ip6.dad_count can
be set to "0" to disable the sleep behaviour. This
needs to be extended one way or another. More soon.
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.
