Most of this will only be relevant for 19.1 where we shall have
an "enforcement" of mtree files through the sets so that this
check can audit our whole system for issues... :)
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.
* Base unbound is no longer installed. Path is /usr/local/...
* remotecontrol.conf is not enough, need to use unbound.conf
* shuffle remote-control content into unbound.conf
* disable cache dump / load until its more clever
Case in point of how useless is it to have unused scripts hitching
along for the ride.
Now that we have metadata injection at build time read it instead
of its auxiliary files. Allow live-mount to snoop the metadata and
afterwards we can start to marry the version and firmware-product
file.
Last puzzle piece will be a tool called "opnsense-version" to read
the JSON metadata and return it in a piecemeal fashion of a part
of the system requires that info, especially from the shell.
We already know a new kernel/base is there, but look up the old
one which may fail if it has been deleted. This causes the sets
to be omitted from the update list, even though later on the
upgrade works as expected.
This is only an improvement and unification of
`src/opnsense/scripts/shell/banner.php`.
Using `openssh_enabled()` both times in this file is preferred over one
time using `isset($config['system']['ssh']['enabled'])` and the other
time using `openssh_enabled()`.
Updates: 00f9b21cb78d9f76a8f94e8e62cbcefad65b7d99
Updates: 81e50abd0afba2d58ce487cdad60c7aedf899bbf
Updates: https://github.com/opnsense/core/pull/2481
Example output:
```
$ /usr/local/etc/rc.initial.banner
*** test-fw.localdomain: OPNsense 18.1.10 (amd64/OpenSSL) ***
WAN (vtnet0) -> v4/DHCP4: 172.30.23.2/24
SSH: 256 SHA256:fcMIAgT/vZR/TWP0j8AFROTNnudkU1tP9sRhbsIa8vM (ECDSA)
SSH: 256 SHA256:lDenOc5wy2WU0e6sSz2hR9nEFnMqx5c3u1F/pHxgJlY (ED25519)
SSH: 2048 SHA256:dsw9srlQHL0hPJlEdR9rL769N30BTZgXG9gXbdZGOkU (RSA)
HTTPS X.509 cert: SHA256 Fingerprint=F0:E6:EB:31:E8:87:AF:52:16:4E:84:05:3B:6C:03:2C:C1:DF:5A:E7:36:F4:32:44:3B:B5:57:63:97:45:C3:77
```
The list of fingerprints is appended after the interface list because
the interface list might be pretty long and thus would move the
fingerprints out of the screen which we don’t want.
Previously (#2427) I suggested to extract the X.509 certificate from the
xml config but the difficult part for me who is not so familiar with the
implementation of OPNsense is to find the certificate which is actually
used by the local web server. I found that `/var/etc/cert.pem` is used
in the configuration of the local web server and assume that this is the
easier way to implement this in the expectation that the file name does
not change without being also changed in this script and that the file
exists. If it does not exist, OpenSSL would complain with a useful error
message.
This commit is one piece to make fully trusted bootstrapping easier.
Related to: https://github.com/opnsense/core/issues/2427
Tested on: OPNsense 18.1.10-amd64
