CARP: optionally promote/demote on service status event handler.
This adds /usr/local/etc/rc.carp_service_status.d/ to register service check scripts, which on failure exit are considered blocking for normal service operation.
A service should emit the following on status change, which in response might lead to change of carp status:
configctl interface update carp service_status
The included early script assures an initial demotion value before interface setup.
ref https://github.com/opnsense/core/issues/3636
usage: pluginctl [-h] -[c] [-s] [arguments]
optional arguments:
-h show this help text and exit
-c configure mode (default), executes plugin [_configure] hook
-s service mode (e.g. myservice restart)
without arguments, a list of plugins of the requested type is shown
For legacy components route -s option through plugins_services()
to get a list of services that can be controlled like the GUI
controls. E.g.:
# pluginctl dhcpd [start|stop|restart]
PR: https://forum.opnsense.org/index.php?topic=12781.0
This is for consistency with hard disk device visibility as it
could be mounted / active. While here, stop cleaning up MNT as
it is only a directory in /tmp that should cause issues...
We already have "kernel" and "base" and plugins also follow this
pattern by only registering its name once per devel or release
version. This kills ambiguity for "opnsense" vs. "opnsense-version"
and makes it more branding friendly. Suffice to say "core", "kernel"
and "base" are reserved names and also align with tools.git.
product_flavour is embedded in the release package but the
package itself does not insist on a particular flavour other
than having knowledge about the flavour the package was
built for originally. This is ok and direct crypto deps
seem to have failed to produce reliable upgrade / sidegrade
results in recent tests anyway.
Long story short: find out the real crypto flavour installed
from the OpenSSL binary or fall back to the metadata if said
binary cannot be found.
Otherwise we try to unload when it's there. Logic was
correct but -b assumtion was incorrect as we do not touch
drivers there or require any pool listing.
/dev/zfs/pool does not exist so we can do a "zfs/pool" input
in alignment with gmirror and graid inputs. Move the probing
after zfs load to be able to unload again also.
If the user's existing subnet isn't 192.168.1.1/xx, then telling the user to use this IP will fail. So tell the user how to set a different IP after reboot, rather than just telling them to use an IP that won't work for them.
Kept short this time - 1 line only :)
Also edited wording re certificate, to be clearer about this as well, by starting with what they will actually see (*"Your browser may..."* rather than *"You might need to..."*). Added just 1 line there as well.
Sorry for these - hopefully not overdoing it. (I'm a fan of making life fun for newcomers, and install is where newcomers first see if a thing works for them!) Perhaps they can be squashed down to save text space. If so please do.
